Fake GIWA Chain Drains $2M: Right Chain ID, Wrong Operator, One Upgrade Transaction

TL;DR

On September 26, 2026, someone deployed a real OP Stack rollup on Ethereum and gave it chain ID 9134, the identifier reserved for GIWA, the Ethereum layer 2 that Upbit operator Dunamu has not yet launched on mainnet. Multichain DEX DYORSWAP took it for GIWA mainnet and added support; by its own count 1,335 addresses bridged about 767.65 ETH into the chain before about 766.25 ETH left in a single transaction, roughly $2 million according to Cointelegraph. The operators held the upgrade key to the bridge, swapped its code for a withdrawal function, paid themselves, and swapped the original code back, all inside one Ethereum transaction at 07:29:59 UTC on September 27. That was less than 12 minutes after GIWA's official account posted that its mainnet was not running. About 705 ETH of the take has since gone into Tornado Cash. DYORSWAP says its own contracts were not compromised and has paid more than 200 ETH to affected users from its own funds. The chain ID was GIWA's own reserved number. The question a listing check had to ask was who holds the bridge's upgrade key.

What Happened With the Fake GIWA Chain?

A fraudulent network impersonating GIWA drained the ETH its users had bridged in. GIWA is an Ethereum layer 2 built on Optimism's OP Stack by Dunamu; Cointelegraph notes its Sepolia testnet went up in September 2025 and a GIWA-based remittance pilot with Hana Financial and POSCO International followed in April 2026. Mainnet is not live. GIWA's own documentation lists one network, GIWA Sepolia on chain ID 91342, and says of mainnet only that it "is currently under development."

On the weekend of September 26, a network calling itself GIWA mainnet appeared on chain ID 9134. It was a working chain. Bitcoin.com News describes OP Stack-style infrastructure with a working bridge and a batcher, and DYORSWAP's official incident write-up confirms the chain posted transaction batches to Ethereum and that users on it performed real buys, sells and token launches. DYORSWAP integrated the chain, and its users followed.

The bridge was emptied about 13 hours after deployment. DYORSWAP's security notice, at 08:06 UTC on September 27, said "the so-called GIWA Mainnet we previously identified was in fact a fake chain set up by scammers" and that it "used the correct GIWA Chain ID (9134), which made it appear legitimate during our initial verification."

What Does a Chain ID Actually Prove?

A chain ID is a number your wallet mixes into every signature so that a transaction signed for one chain cannot be replayed on another. That is the whole job. EIP-155, titled "Simple replay attack protection," introduced it in 2016. Nothing in the mechanism binds the number to an operator. Anyone can run a node that reports chain ID 1.

A registry's job is to stop two chains claiming the same number. Who runs a chain is outside its scope. The public ethereum-lists registry entry for 9134 names the chain GIWA, lists no RPC endpoint and no explorer, and carries the status "incubating." It went in alongside the Sepolia entry in a commit titled "Add giwa testnet and mainnet". So 9134 really is GIWA's reserved number.

Seoul Economic Daily reported that third-party chain sites had wrongly listed 9134 as GIWA mainnet and noted that the testnet's ID is 91342, which reads as 9134 with one digit added. DYORSWAP calls it the correct ID. Both hold up: 9134 is the reserved mainnet number, and the reservation told anyone who read it that no mainnet had been launched yet. An empty RPC list on a chain that is suddenly live and taking deposits is the tell, and the scammers had squatted exactly that reserved number.

How Did the Operators Take the ETH Out?

They upgraded the bridge. An OP Stack chain's L1 bridge is the OptimismPortal, a contract that holds every deposited ETH, and it sits behind a proxy that an admin contract can point at new code. Whoever controls that admin controls the money. This is by design: it is how legitimate rollups ship fixes.

The fake chain was deployed through Optimism's own tooling. The deployment transaction at 18:10:59 UTC on September 26 calls a contract Blockscout labels OPContractsManagerV2, which the OP Stack specification describes as a contract that "deploys the L1 contracts for an OP Stack chain in a single transaction." The spec adds that the version deployed "is always a governance-approved contract release." The portal, the bridge and the proxy admin were stock Optimism code. Anyone reading the contracts found a normal rollup.

What was not normal was the owner. Reading the Safe's owner list and threshold directly on-chain, the proxy admin is controlled by a Safe multisig with a threshold of two, and its two signers are the deployer address and the address DYORSWAP identifies as the chain's batcher. Nothing on-chain shows whether one person holds both keys. Both belong to the chain's own operators, though, so the multisig added no outside check on the bridge (a multisig in form only). Shared funding between the two keys would settle whether they are one person; DYORSWAP lists batcher-related infrastructure among what it is still tracing.

The drain used that authority exactly as designed. Reading the transaction trace:

1. The deployer submitted a Safe transaction carrying both signatures.
2. The Safe delegatecalled a helper contract, which told the proxy admin to upgrade the portal proxy to a new implementation at 0x9D32...1bEc.
3. The proxy called the new code, which sent 766.254 ETH to a fresh address.
4. The proxy admin upgraded the portal back to the stock OptimismPortal2 implementation.

Two Upgraded events fire in the logs, one to the drain code and one back. The portal held exactly 766.254 ETH in the block before and zero after it, so the drain took everything the bridge held at that moment. After the block the portal looks exactly as it did before, minus the money.

DYORSWAP's figure for ETH bridged in, 767.65, is about 1.4 ETH higher than what the portal held at the drain. We have not reconciled that gap; withdrawals processed before the drain or a difference in how deposits were counted would both explain it. The drain was atomic. Nobody could react.

The Attack, Step by Step

Where Did the 766 ETH Go?

Most of it is in Tornado Cash. We traced the receiving address on Blockscout. Within 50 minutes of the drain it had split the take three ways, and all three branches fed the mixer.

The branches add to about 704.9 ETH in Tornado Cash, roughly 92% of the drain, the last of it by 11:18 UTC on September 28. Protos also reports the proceeds were funneled into the mixer. About 60 ETH went to an address we have not followed past the first hop.

The bridge also kept taking money after it was empty. The portal proxy's history shows 25 more deposits worth about 2.71 ETH arriving after the drain, the last at 17:47 UTC on September 27, ten hours later. That is exactly the balance the portal holds today.

There is a stranger detail in the receiving wallet's history. Dozens of dust transfers arrive from addresses that begin 0x8c56 and end 3dA4, or begin 0xEC16 and end 6b60, matching the two addresses the thief had just paid. That is address poisoning: lookalike wallets seeding the history in the hope the next copy-paste picks the wrong one. Other scammers went after the scammer within minutes of the first transfers.

On September 28 at 09:43 UTC, DYORSWAP sent the deployer an on-chain message saying it had reconstructed the deployment, the batcher activity and the fund movements, and offering "a reasonable whitehat bounty" for a voluntary return. No return has been observed.

What Did It Cost the Attackers?

Almost nothing. DYORSWAP traced the deployer's funding to a single transfer of 0.04536522145 ETH. The deployment transaction burned about 0.0103 ETH in gas; the drain burned under 0.00001 ETH. Against 766.25 ETH out, the seed money returned roughly 16,900 times.

The preparation was cheap too. Of the three wallets that made the first deposits 39 blocks after deployment, two had been funded about 25 days earlier, one from Binance and one from Gate, and then left idle, per DYORSWAP's tracing. DYORSWAP calls them "strongly consistent with pre-positioned internal testing wallets" and labels that a behavioral assessment. The social layer is described but not public: DYORSWAP's security notice says it "identified specific suspicious messages and individuals in the related community." Users quoted by Bitcoin.com News called it social engineering; the messages themselves have not been published, so how the chain was introduced to DYORSWAP remains unconfirmed.

The timing of the exit is suggestive. GIWA's post at 07:18 UTC read "We DO NOT have our mainnet running currently. Any of those posts claiming that they have GIWA mainnet RPC information are NOT TRUE." The drain landed less than 12 minutes later, and the code that performed it did not exist when GIWA posted: the deployer created the drain implementation at 07:29:35 UTC, two blocks and 24 seconds before using it. Nothing on-chain proves the post triggered the exit. The shape fits operators who kept the chain running as long as deposits flowed and deployed their withdrawal code once the official denial landed.

Why Did a Contract Review Have Nothing to Find?

The contracts were fine. The bridge ran the same governance-approved OP Stack release that legitimate rollups run, and the portal did what a portal is meant to do: move ETH when its admin tells it to.

A clean audit certifies code. On an upgradeable bridge the real security boundary is whoever holds the upgrade key, and a review of stock contracts has nothing to say about them. We made the same point when B² Network lost $3.86 million to a compromised upgrade authority. There the key was stolen. Here the operators held it from the first block.

The closest precedent is an identity failure too. In August a cloned interface on Tornado Cash's lapsed original domain cost a user 810 ETH, a real name in someone else's hands. Chain IDs and domain names are both identifiers anyone can reuse. The question that matters for custody is who can move the money.

For an integrator, that question has a mechanical answer. Read the portal's proxy admin, read its owner, read the owner's signers, and check how old and how funded they are. Here the answer was a two-of-two Safe controlled by a deployer that had existed for hours and was funded with a fraction of an ETH through an instant-exchange service, and reading it takes a few RPC calls.

What Should Operators Do?

1. Verify a new chain against the project's own channels. A chain ID registry prevents collisions and stops there: it will happily list a number for a chain that has never launched. Require the chain's RPC, explorer and bridge addresses to appear in the project's documentation or signed announcements before listing. GIWA's docs never listed 9134.
2. Read the bridge's upgrade authority before you route user funds into it. For an OP Stack chain: portal proxy, proxy admin, admin owner, owner's signers and threshold. Treat an owner that is a fresh EOA, or a multisig whose signers are the chain's own deployer and batcher, as a blocker.
3. Check how the deployer was funded and how old it is. A mainnet whose L1 contracts are hours old, deployed by an address seeded with 0.045 ETH from an instant exchange, is not a mainnet launch.
4. Put an exposure cap on any chain you list before its official launch. DYORSWAP's own users ended up trading on the chain in 298 wallets across 104 pools. A per-chain deposit ceiling for unverified networks bounds the loss to what you can compensate.
5. Alert on Upgraded events on every bridge you depend on. An upgrade you did not expect on a portal holding your users' deposits is the one event that should page someone, day or night.

Where Would Monitoring Have Fired?

The drain was one atomic transaction, so alerting could not have saved the 766 ETH. The pre-listing questions above are integrator diligence, run once. Monitoring owns the aftermath: how fast a listing comes down and how much more money walks into a bridge that is already empty.

A Tripwire watch on the portal of a chain DYORSWAP had listed would have had concrete events to fire on. At 07:29:35 UTC a Safe signer that controls the bridge's proxy admin deployed a brand-new contract, a 24-second lead that gives a responder context rather than time. In block 26067309 the portal proxy emitted two Upgraded events inside one transaction, and 766.254 ETH, effectively its whole balance, left in the same call. That alert fires in the drain block itself. After it, 25 more deposits worth about 2.71 ETH arrived over ten hours, each one a deposit into a bridge with nothing left in it. DYORSWAP's public warning went out 37 minutes after the drain. We build those rules for teams whose users' funds sit behind someone else's bridge, so the page arrives in the drain block and the delisting does not wait 37 minutes for a public post.

Frequently Asked Questions

Was GIWA hacked?

No. GIWA's real network, the Sepolia testnet on chain ID 91342, was not involved, and GIWA had not launched a mainnet. A separate network impersonated it on GIWA's reserved chain ID 9134. Seoul Economic Daily and DYORSWAP both describe it as a separate fraudulent network.

Was DYORSWAP's smart contract exploited?

No. DYORSWAP states "this was not a DYOR contract exploit." The ETH left the fake chain's own bridge, which its operators controlled. DYORSWAP's failure was listing the chain, and it has paid more than 200 ETH to affected users from its own funds, including a 40% refund for addresses that bridged under 5 ETH, per Protos.

How much was stolen in the fake GIWA scam?

About 766.25 ETH, roughly $2 million, from 1,335 addresses that bridged about 767.65 ETH in total. The on-chain drain transaction moved 766.254 ETH, which matches DYORSWAP's 766.25 ETH drained figure and was the portal's entire balance at that block. We trust the ETH number; the dollar figure depends on the price used.

Can the stolen ETH be recovered?

Not yet. About 705 ETH, roughly 92% of the drain, went into Tornado Cash within about 28 hours. DYORSWAP has offered a whitehat bounty on-chain for a voluntary return, and no return has been observed.

How do you verify a new L2 before bridging to it?

Check the project's own documentation for the network, then check the bridge. Confirm the chain ID, RPC and bridge addresses appear on the project's official site, and read who owns the bridge's proxy admin. A chain ID alone proves nothing about who runs the chain.

Sources / References

• DYORSWAP: Official Update on the Fake GIWA Chain 9134 Incident (X)
• DYORSWAP: Security Incident Notice (X)
• GIWA: "We DO NOT have our mainnet running currently" (X)
• Etherscan: fake bridge deployment transaction
• Etherscan: drain transaction
• Etherscan: drain implementation creation transaction
• Etherscan: DYORSWAP on-chain message to the deployer
• Etherscan: proxy admin owner Safe
• Etherscan: deployer address
• Etherscan: drain receiving address
• Blockscout: drain receiving address
• Blockscout: fake GIWA portal proxy
• Cointelegraph: Scammers Steal $2M in ETH as Fake GIWA Network Fools DYORSWAP
• Protos: DYORSWAP users tricked into sending 767 ETH to fake bridge contract
• Bitcoin.com News: Scammers Launch Fake ETH L2 to Steal $2M From Crypto Traders
• Seoul Economic Daily: Fake Chain Posing as Upbit's Unlaunched GIWA Network Drains 767 ETH
• GIWA Documentation: Connect to GIWA
• ethereum-lists/chains: eip155-9134.json
• ethereum-lists/chains: Add giwa testnet and mainnet (#7707)
• EIP-155: Simple replay attack protection
• OP Contracts Manager, OP Stack Specification