On September 18, 2026, the GIWA ecosystem had a good news cycle: GIWATER, a DEX selected for Upbit’s GIWA ecosystem incubation program, announced it had integrated a trading-card-game application — the first DEX in the Korean market to do so. GIWA itself is an Ethereum Layer 2 being built with Upbit, the largest Korean exchange, aimed at the Korean market. Its name recognition has been climbing since Dunamu filed GIWA trademarks a year ago.

Eight days after that announcement, a swap frontend branded DYORSWAP opened for business — and over the following fourteen hours, 1,331 unique addresses on Ethereum mainnet paid a combined 771.18 ETH into a contract they believed was the GIWA bridge.

This article reconstructs the operation from on-chain data we pulled ourselves — full transfer history paged through Etherscan’s API, storage slots, balance snapshots at the block level, and the laundering chain. No screenshots, no secondhand numbers. The scam’s design is worth studying in detail, because its central trick defeats the most common piece of due-diligence advice in crypto: “check the contract on Etherscan.”

What a fake RPC actually controls

Every wallet talks to a chain through an RPC endpoint. Most users never think about theirs, because it arrives pre-configured. That is exactly the seam this attack targets.

If a frontend, tutorial, or “helpdesk” agent convinces you to point your wallet at an attacker-controlled RPC, the attacker now controls what your wallet shows you. Your keys never leave your device — they don’t need to. A fake chain can display a balance that appears to arrive after you bridge. It can confirm transactions that happened nowhere. It can present any contract under any name.

In this incident, victims were onboarded to “GIWA” through the DYORSWAP interface, complete with a cross-chain bridge flow. The fake RPC made the theater self-consistent: you deposit, the fake environment shows your funds arriving on the “L2,” and nothing about the experience feels wrong. The theft is invisible at the moment it happens — the theft is the deposit transaction.

One detail from the transfer data shows how deep the theater went: the fake portal received 0.05 ETH on Sepolia and 0.01 ETH on Arbitrum. Some victims were walked through configuring an entire custom network — testnet credentials and all — before being routed to the mainnet deposit. When a “mainnet bridge” asks you to add a testnet, you are standing inside someone’s soundstage.

This is phishing upgraded from faking a login page to faking a chain’s entire view of the world.

The verified-contract trick

The deposit contract is 0xba9938c0b96a70e6479661b915e7e481fe435ab2. Pull its code: a standard ERC-1967 proxy pattern, implementation slot resolving to 0xe89f13c5ee4033b2d3cd76c9d6958efbfe26d3c2 — a fully Etherscan-verified OptimismPortal2.

Pause on that. OptimismPortal2 is the real OP Stack portal contract — the contract family OP Mainnet, Base, and OP-Stack Layer 2s like GIWA use to receive deposits on Ethereum. The attacker deployed a proxy delegating to the genuine, verified implementation. A cautious victim who checked the contract before depositing saw a green checkmark and audited OP Stack source. Everything looked right. Two things were fatally wrong:

  1. The storage belongs to the proxy’s deployer. ETH sent to this contract sits in the attacker’s proxy, not in any canonical portal.
  2. The L2 never hears about it. An OP Stack L2 derives deposits from events emitted by the official portal address. A lookalike emitting identical events changes nothing — no GIWA ledger ever credits these deposits. There is no “the chain will still honor it” edge case.

And a third problem bigger than both: GIWA’s mainnet does not exist. Official documentation states it plainly: “GIWA Mainnet is currently under development.” The only public network is GIWA Sepolia, a testnet. Real mainnet bridge deposits were not possible for anyone, through any interface. The scam monetized a launch that hadn’t happened.

The fake-chain listing: how the official frontend sold the scam

DYORSWAP is not a phishing brand, and — this is the part that rewrites the story — its official frontend was not bypassed either. DYORSWAP published a security incident notice on its verified X account (@DYORSWAPDEX, ~16.5K followers) at 08:06:45 UTC on September 27 that states, in effect, that the platform itself was the distribution channel:

“We have confirmed that the so-called GIWA Mainnet we previously identified was in fact a fake chain set up by scammers. The fake network used the correct GIWA Chain ID (9134), which made it appear legitimate during our initial verification. … Unfortunately, significant losses have already occurred through the fraudulent bridge.”

Read that carefully. “We previously identified” — DYORSWAP had listed this “GIWA Mainnet” as a supported network. Victims were not duped into a lookalike site; they opened the real dyorswap.org, saw a GIWA Mainnet option presented alongside Arc, Base, and Arbitrum, and bridged through it. The notice also confirms the company is engaging security teams for on-chain tracing, preserving “chat records, RPC information, bridge addresses, and on-chain transactions” as evidence — and, notably, preparing to compensate affected users from its own treasury. That compensation commitment is effectively an acknowledgment that the official listing was the funnel.

The mechanism that made it work is depressingly simple: an EIP-155 chain ID is not an identity. Nothing in the protocol prevents anyone from running a chain that self-reports any chain ID they like. The real GIWA testnet runs 91342 (per GIWA’s official docs); the fake mainnet reported “the correct GIWA Chain ID” per DYORSWAP’s notice (which writes it as 9134 — either a truncation in the notice or the attacker’s own choice; we record both rather than resolve it). If a multi-chain platform’s listing verification stops at “does the chain ID match the project’s published one,” then a fake chain with the right ID and an attacker-controlled RPC passes every check — and the platform then lends its domain, its UI, and its reputation to the scam. The user’s own diligence was never given a chance: you cannot out-vet the platform that hosts the button.

This resolves the questions our earlier reconstruction left open — why deposits were plain Ethereum-mainnet transactions (the bridge flow’s L1 leg: an OP-Stack-style depositTransaction on mainnet, with the fake chain’s RPC free to “confirm” arrival on the L2 side that never existed), why the Sepolia touches appeared (users following the full network-add flow), and why the traffic curve looks like a coordinated push aimed at an official-frontend entry point. A chain-level supply-chain attack: not a fake website, not a fake contract — a fake network, wearing the right chain ID, listed on a real platform.

(Note: DYORSWAP’s current public docs list sixteen supported chains and no GIWA — that is the post-incident state, after the fake listing was pulled. Our earlier reading of that page as “GIWA was never supported” was a snapshot fallacy: today’s config cannot testify about yesterday’s.)

The uncomfortable conclusion for every multi-chain platform: your chain-listing process is a security boundary. A chain ID match is a costume, not a credential. Hardening that boundary means verifying out-of-band with the chain’s official channels (published RPC domains, genesis hash, explorer cross-checks — not the candidate chain’s self-reported metadata), and treating any “mainnet” that appears before the project itself announces mainnet as presumptively fake. For users, the lesson lands differently: when the platform lists it, the platform vouches for it — so the failure you must insure against is no longer your own vigilance, it’s the platform’s.

The deposit curve: a pump, not a search result

The full transfer history — 2,297 direct deposits, paged end to end — has a shape, and the shape tells you how victims arrived.

Fake-portal deposits over time: green bars are ETH per 5-minute bucket, amber line is cumulative total

Hourly view: transfers (bars) and ETH (line). Red columns mark the three pump hours

Hour (UTC, Sep 26–27)DepositsETH
Sep 26, 18:00–23:59161.13
Sep 27, 00:00–01:5973.42
Sep 27, 02:003211.22
Sep 27, 03:00748174.57
Sep 27, 04:00685269.00
Sep 27, 05:00445225.59
Sep 27, 06:0023449.28
Sep 27, 07:0013120.30

The first night is a trickle — one or two deposits an hour, the profile of stragglers finding a phishing link organically. Then at 02:00 the flow picks up, and from 03:00 to 05:59 the fake portal ingests 1,878 transactions and 669 ETH in three hours — 82% of the entire haul. That is not SEO. That is not word of mouth. That is a distribution pump: a link pushed simultaneously through channels with reach, most plausibly Korean-language Telegram groups and social feeds, timed for midday Korea (03:00–06:00 UTC is noon–15:00 KST) when retail users are on their phones.

The deposit sizes confirm retail: median deposits are small, the largest single transfer in the entire dataset is 19 ETH, and 89 internal transfers worth 16.71 ETH arrived via just two intermediary contracts — consistent with routing contracts the fake frontend used to batch some deposits. This was a crowd-fleecing operation, priced for everyone.

We deliberately do not name any promoter accounts seen pushing DYORSWAP-style links in that window: distribution affiliates are often unaware of what they are distributing, and the operators are the story. The pattern itself — a burst of coordinated traffic aimed at a fake frontend during a pre-launch hype window — is what matters, and it will be reused.

The exit: one transfer, then 50-ETH blocks

  • Sep 27, 07:29:59 UTC — An executor contract 0xccc2aecf5d24f0ea30cf81ec0dbec59f19ddcd10, whose first-ever activity is this same minute, receives an executeTransaction call from the operator EOA. One internal transfer moves 766.254042109579 ETH out of the fake portal to 0x04a9c8d8fee491411bda28b68ad80f0122fc4134 (tx) — a fresh address whose own first outgoing activity begins twelve minutes later. Block-level balance checks confirm the portal held exactly 766.254 ETH immediately before the sweep and ~0 after.
  • 07:41–07:53 — The destination peels 251 ETH in 50-ETH blocks to 0x8c563fc543f6ecc2c8c09eb09d82798f7a7f3da4 (1 + 50 × 5).
  • 07:57–08:05 — Another 301 ETH in the same 50-ETH blocks to 0xec160acd00d95ebbbe0394161101eb577ca96b60 (1 + 50 × 6).
  • Afterward — 0xec16...6b60 had already forwarded 87 ETH onward in 15 transfers to a next-hop address by the time of our analysis; 0x8c56...3da4 was still untouched; the root 0x04a9...4134 still held 217.25 ETH. Standard layering — split, fan out, stage for whatever comes next (mixer, cross-chain hops, OTC).

Fund flow: 1,331 depositors → fake portal → single sweep → 50-ETH block layering

The books balance to the wei: 771.18 ETH in, 766.25 swept, ~1.39 ETH residual plus gas. Nothing about the exit was improvised — the executor was deployed in the same minute it was used, the sweep destination was fresh, and the sub-wallet structure was waiting. This was an operation with a closing checklist, executed at 07:29 UTC the morning after the pump, one hour before the last stray deposit arrived at 08:04.

The infrastructure cluster

Assembling the addresses from deployment records, storage slots, and funding flows:

  • Operator EOA 0x119e68b59c44291f76324c76377b776d0b4dd38c — first mainnet activity September 26, 09:47 UTC, funded with 0.045 ETH of gas by 0x016606ac...49ee, an address with history back to 2022. Nine hours later it deploys; nine hours after that the first victim deposits.
  • Fake portal proxy 0xba99...5ab2 — ERC-1967, admin slot 0x91afa0ac...2472, implementation = verified OptimismPortal2.
  • Executor 0xccc2...cd10 — born and used in the same minute for the 766.25 ETH sweep.
  • Sweep destination 0x04a9...4134 and sub-wallets 0x8c56...3da4, 0xec16...6b60.

Five contracts/addresses and one EOA, purpose-built, used for roughly 22 hours of wall-clock time from first funding to final peel. The cluster fingerprint — a fresh EOA funded by an older address, a proxy wearing verified code, an executor deployed at moment of use, 50-ETH block layering — is the kind of signature that can be matched against future campaigns. We are keeping the full transfer dataset.

Contract review: why every check passed

We ran a structured review of the deposit contract’s architecture (AI-assisted, DeepSeek v4 Flash, against the on-chain state we pulled). Verdict and key findings:

[Critical] A verified OptimismPortal2 implementation behind a lookalike ERC-1967 proxy, plus a fake chain environment, turned depositTransaction into unrecoverable ETH transfers. No OP-Stack derivation will ever honor them.

  • Proxy/implementation verification gap. The proxy holds the balance and storage; the admin slot (0x91af...2472) can replace the logic at any time. Verifying the implementation only proves its bytecode matches source — not that this proxy is canonical, not that it is immutable. Detect: read the EIP-1967 impl/admin slots; compare all three addresses against official docs and L2Beat.
  • depositTransaction semantics abused. On a real portal it locks ETH and emits TransactionDeposited; L2 derivation only watches the canonical portal address. Here the proxy accepts ETH and may emit lookalike events, but no real L2 exists to listen. Detect: treat an L1 transaction success as bridge credit only after confirmation on the official L2 explorer.
  • Chain spoofing via custom RPC. Wallets trust RPC-provided chain metadata; the fake environment made “GIWA” appear live and Upbit-backed. Detect: take RPC endpoints from official docs only; verify chainId and genesis hash independently.
  • URL-parameter chain config. A multi-chain frontend driven by ?chainId= becomes an untrusted config loader if it follows wallet context blindly: whoever controls the RPC controls chain identity, contract addresses, and what “success” looks like. Detect (for dApp builders): hardcode an allowlist of chainId → RPC → canonical contracts; never derive bridge addresses from wallet-provided state.

The full pattern is worth stating plainly: users were told to “check the domain, check the contract.” They did. Both checks passed. The attack lived one layer below both.

Why the timing was the weapon

Every element was scheduled around GIWA’s visibility curve. The TCG integration put “GIWA ecosystem” into news feeds on September 18. The operator address woke up eight days later. For a mainnet that has not launched, the window between “famous enough to search for” and “real infrastructure exists to compare against” is not a gap — it is the entire opportunity. No canonical bridge address to diff against, no docs habit formed yet, and a population of users primed by a year of GIWA headlines to want in early.

Korea-specific context made it worse. Upbit’s user base has been repeatedly targeted by impersonation phishing, and GIWA hype has already produced one official debunking — Upbit had to deny a fake stablecoin-launch rumor in 2025. A market that is both excited and warning-fatigued is exactly where a fake “early bridge” converts best.

How to verify a real bridge, in order

  1. Does the mainnet exist at all? Official docs only. If the project’s own documentation says mainnet is in development — as GIWA’s does today — every “mainnet bridge,” “early deposit,” and “genesis liquidity” offer is fiction. Not risky. Fiction.
  2. Take RPC endpoints from the official docs domain. Not from a chat group, an app’s onboarding screen, or a helpful stranger. A fake RPC invalidates every subsequent check — it is the root of trust for everything your wallet displays.
  3. Diff the address, not the code. The canonical portal for any OP Stack L2 is a specific address published in official docs and tracked on L2Beat. A verified OptimismPortal2 at any other address proves only that the attacker copied good code.
  4. Treat testnet touches as red flags. A “mainnet bridge” flow that asks you to add a testnet or approve contracts on a network you didn’t choose is staging a play for you.
  5. A chain ID is a costume, not a credential. Nothing stops an attacker’s chain from self-reporting the same ID a real project publishes. Platforms and users verifying a “new mainnet” should demand out-of-band proof: the project’s own announcement, official RPC domain, genesis hash — not the candidate chain’s self-description. A “mainnet” that exists on a multi-chain app before the project announces mainnet is presumptively fake.
  6. Beware the traffic source. An interface that reached you through a group chat blast at lunchtime, rather than an official channel, is the distribution pattern of this exact scam. If a “GIWA” or pre-launch app link is circulating in a Telegram group, that circulation is the warning, not the social proof.
  7. If it already happened: stop using that wallet session, preserve URLs and transaction hashes, and follow the post-incident checklist in what to do after a wallet drainer.

The pattern to remember

Strip away the Korean-market specifics and the structure is generic: a pre-launch window, a famous name, a coordinated traffic pump, a self-consistent fake environment, and a real verified contract doing a job it was never authorized to do. The recipe ports to any L2 before mainnet, any “ecosystem partner” announcement, any wallet that accepts custom RPCs.

The defense is unglamorous and absolute: before a mainnet exists, there is nothing to bridge to. Anyone who tells you otherwise is early to something — just not to the chain.

On-chain data queried via Etherscan APIs and block-level balance reads at the time of writing; balances and activity may have changed since. Addresses: fake portal proxy 0xba99...5ab2 · verified implementation 0xe89f...d3c2 · operator EOA 0x119e...d38c · executor 0xccc2...cd10 · sweep destination 0x04a9...4134 · sub-wallets 0x8c56...3da4, 0xec16...6b60.

Frequently Asked Questions

What is a fake RPC attack?

A fake RPC attack replaces the server your wallet talks to. Your seed phrase never leaves your device — the attacker does not need it. Whoever controls the RPC controls what your wallet shows you: fake balances that look like your bridge deposit arrived, fake confirmations, fake contract names. The theft is the deposit transaction itself, signed with your full consent in an environment where nothing you see is real. In this incident some victims were even walked through adding a full fake chain config, testnet included — one sent 0.05 ETH on Sepolia to the scam address.

Why did the contract show as verified on Etherscan? Isn't that a safety signal?

The proxy at 0xba99...5ab2 points to the genuine OptimismPortal2 implementation, which is independently verified. Etherscan's green checkmark means 'this bytecode matches this published source code' — it does not mean 'this address is the official bridge of any chain.' Anyone can deploy a proxy delegating to any verified public source. The check to run is whether the address itself appears in the project's official docs or on L2Beat as the canonical portal — not whether the code looks legitimate.

How much was stolen, and how many victims?

1,331 unique depositor addresses sent a combined 771.18 ETH on Ethereum mainnet between September 26, 18:18 UTC and September 27, 08:04 UTC: 2,297 direct transfers worth 754.46 ETH plus 89 internal transfers worth 16.71 ETH routed through two intermediary contracts. Small satellite amounts also reached the address on Arbitrum (0.01 ETH) and Sepolia (0.05 ETH). The largest single deposit was 19 ETH; the bulk were retail-sized. The operators swept 766.25 ETH out in one transfer at 07:29 UTC on September 27.

Was DYORSWAP itself the scam, or was it hacked?

Neither, by the evidence available: DYORSWAP was the deceived platform. Its official security notice confirms the fake GIWA Mainnet 'used the correct GIWA Chain ID (9134), which made it appear legitimate during our initial verification' — meaning DYORSWAP listed the counterfeit chain as supported, users bridged through that official listing, and the platform is now funding compensation from its treasury. The scam was a fake network wearing a real chain ID, listed on a real frontend. The deposit contract (0xba99...5ab2, a proxy to verified OptimismPortal2) was never part of DYORSWAP's legitimate configuration — it was the bridge target inside the fake chain's context.

Where did the stolen funds go?

At 07:29 UTC on September 27 the haul moved from the fake portal to a fresh address (0x04a9...4134). Within 36 minutes it began peeling 50-ETH blocks to two sub-wallets: 251 ETH to 0x8c56...3da4 (still untouched at the time of our analysis) and 301 ETH to 0xec16...6b60, which had already forwarded 87 ETH onward in 15 smaller transfers. The root address still held 217.25 ETH. Standard pre-mixer layering; no exchange deposit had been identified at the time of writing.

How do I verify I am using the correct RPC and bridge for an L2?

Take both from the project's official documentation domain only — for GIWA that is docs.giwa.io, which publishes its endpoints and currently states the mainnet is under development. Never accept an RPC URL or chain config from a chat group, an app's onboarding screen, or a site you reached through an ad. Verify the bridge contract address against official docs or L2Beat, and treat 'mainnet not launched yet' as an absolute stop: no real deposits exist before a real mainnet does.