Gord

Centralized Launchpad on GIWA

[Gord @gordpro_]

https://t.co/dyrmo41xpv

[Gord @gordpro_]

Over the past few hours, quite a few people mistook a chain using "chain Id 9134" for the GIWA mainnet.

We were confused by the RPC for a while as well, but because we could not find any signal strong enough to identify it as Upbit’s official mainnet, we did nothing.

There does not seem to be much written yet explaining the technical side, so I am putting this together in the hope that it helps.

The scam chain was built on a real OP Stack.

The RPC worked. The bridge accepted deposits. The chain ID was "9134", the number GIWA had reserved. It was deployed through OP Contracts Manager, and the contracts returned "version()" strings matching the standard OP Stack release.

On the surface, it looked convincing.

The problem is that all of these signals are reproducible.

A chain ID is just a number. A permissionless factory can be used by anyone. Anyone can run an RPC. And standard OP Stack code can be forked while leaving the "version()" string untouched.

That is exactly what happened here.

When we compared the L2 predeploy bytecode against the standard "op-contracts v7.0.0" build, several core contracts had different code sizes and hashes.

The "version()" string matched.

The code did not.

The larger problem was the key topology.

The Owner, Guardian, Challenger, and ProxyAdmin owner all sat under the same 2-of-2 Safe, whose only signers were the deployment hot wallet and the batcher hot wallet.

The keys operating the chain were effectively the same keys capable of draining it.

A few hours later, that authority was used.

Deployment and batch submission were funded with only around "0.054 ETH" from an anonymous swap-service hot wallet. After 200+ batches, the batcher was nearly empty.

That looks nothing like a production L2 preparing a serious blob budget.

The withdrawal path was equally problematic.

Anyone could deposit, but exits depended on a permissioned dispute path controlled by the operator.

Anyone could put money in, but getting money out required the operator’s permission.

And the operator got out first.

This reinforced one rule for us.

When identifying a real chain, the most important signal is not the chain ID, RPC, or factory.

It is the anchor.

An anchor is something the operator cannot reproduce alone:

- Infrastructure under the actual brand domain
- External protocols deploying with their own keys
- Official node-provider listings
- Official node images, genesis files, or snapshots
- Key history connected to the testnet
- Production-level batcher funding

The "9134" chain had none of them.

What it had were things anyone could reproduce:

A chain ID. An OPCM deployment. An RPC. A bridge. A version string.

And the ETH of people who believed those things were enough.

We detected this chain as a launch candidate, but Gord’s watcher kept it PENDING because the owner was unexpected and there was no "https://t.co/tPdE06t1Q0" binding.

This is why we care more about verifying that a chain is real than simply getting there first.

Official announcements can be slow, and the real GIWA mainnet could appear onchain before an official announcement.

So our rule is not:

“No official announcement means fake.”

We look for infrastructure anchors.

Does infrastructure appear under the GIWA domain?

Do the predeploys match GIWA’s actual stack?

Is the batcher posting blobs with a production level budget?

Are governance and operational keys separated?

Are external node providers and protocols recognizing the network?

If those signals are there, we may identify the real network before an official tweet.

If they point the other way, as they did this time, we stop.

Gord will open when the real GIWA mainnet goes live.

We have no intention of becoming a “first mover” by deploying onto a fake chain.

We do not need to open a few hours earlier. We need to be there on day one of the real GIWA.

We deeply regret what happened on "9134", and sincerely hope those affected are able to recover their losses.