Root Cause
The core vulnerability is the public pre-announcement of Chain ID 9134 by the GIWA project before its mainnet launched. Attackers registered OP Stack infrastructure under that exact Chain ID and RPC endpoint, creating a fully functional counterfeit Layer 2. The OP Stack bridge model has no on-chain registry of canonical rollup deployments — any deployer can stand up a portal contract on Ethereum mainnet that accepts ETH "for" an arbitrary chain.
// Simplified OP Stack L1 deposit (any portal can accept ETH)
// No canonical registry distinguishes legitimate from fraudulent portals
// Users were directed to call deposit on an attacker-controlled portal address
function depositTransaction(
address _to,
uint256 _value,
uint64 _gasLimit,
bool _isCreation,
bytes memory _data
) external payable;
// ETH arrives in attacker-controlled portal; fake L2 mints shadow bridged tokens
// Attacker then withdraws ETH directly from the portal with no challenge period
The DYORSWAP DEX independently listed the fraudulent RPC endpoint as the genuine "GIWA Mainnet," accelerating deposit inflow.
Attack Steps
| # | Action | Detail |
|---|---|---|
| 1 | Chain ID squatting | Attacker deploys OP Stack L2 node set with GIWA's announced Chain ID 9134 |
| 2 | RPC masquerade | Registers attacker-controlled RPC endpoint resembling GIWA's expected endpoint |
| 3 | DEX integration | Fake chain gets listed on DYORSWAP as "GIWA Mainnet" in its network selector |
| 4 | Deposit accumulation | 1,335 Ethereum wallets bridge ETH to the fake L2 over several hours (Sep 27–28) |
| 5 | Drain | Attacker removes 766.25 ETH from the portal-equivalent contract on mainnet |
| 6 | Exit | ETH moved to attacker-controlled wallets; GIWA warns publicly that mainnet is not yet live |
| 7 | Partial restitution | DYORSWAP self-funded ~200 ETH to compensate affected users |
Impact
- 766.25 ETH (~$2.08M) drained from 1,335 addresses
- DYORSWAP compensated ~200 ETH from own treasury
- Net user loss:
566 ETH ($1.5M unrecovered) - Real GIWA project has no smart contract vulnerability; only its pre-announced Chain ID was exploited
- DYORSWAP clarified its core contracts were not compromised
Lessons for Auditors
- Never pre-announce a Chain ID before deploying RPC infrastructure. A publicly committed Chain ID is a squattable namespace — any OP Stack operator can deploy a portal accepting ETH for that chain immediately.
- OP Stack trust model is permissionless. There is no on-chain registry of canonical L2 deployments on Ethereum. Users and integrators must independently verify portal contract addresses against official project channels, not DEX UI labels.
- Aggregator/DEX vetting gap. Aggregators and multi-chain DEXs listing L2 RPC endpoints should verify: (a) the chain ID matches an official on-chain deployment, and (b) the portal address is published by the project's own DNS/ENS record.
- Mitigation options. Projects could register an ENS name or use on-chain attestation (e.g., EAS) to bind a canonical portal address to a chain ID before public announcement. An Ethereum-level L2 registry contract (similar to EIP-3770 chain shortnames) could formalize this.
- Auditor checklist addition. When auditing bridged protocols or cross-chain deployments, confirm the client has secured their planned Chain ID in their deployment infrastructure before any public communication.