The RPC That Never Was: A Forensic Read of GIWA, Upbit's Unlaunched Layer 2

Hook

"GIWA's mainnet RPC was never launched."

Six words. No contract address. No block height. No audit reference. No commit hash. Just a denial, issued from a project account, paired with a warning that users should be wary of FUD and of impersonation scams.

That is the entire news event. A Layer 2 built by Dunamu — the parent company of Upbit, South Korea's largest exchange — took to its official channel to state that something which many people apparently believed existed did not, in fact, exist at the layer they thought it did.

I have spent a decade reading disclosures that were engineered to look like disclosures while revealing nothing. This one is different. This one is a denial engineered to look like a denial while revealing something quite specific. The tell is not the word "never." The tell is the word "mainnet."

Follow the hash, not the hype. When a sentence hedges its own scope, the hedge is the story.

Context — What We Are Actually Looking At

Strip away the noise and the underlying facts are thin. GIWA is an Ethereum Layer 2 developed by Dunamu, the Korean entity behind Upbit. It is built on the OP Stack — the same open-source rollup framework that underlies Coinbase's Base, Optimism's mainnet, Uniswap's Unichain, and Sony's Soneium. It is EVM compatible. Its publicly stated performance target has been reported as one-second block times. And, per the project's own clarification, it remains in a testnet phase with no live mainnet.

That is the foundation. Nine facts, maybe ten, depending on how you count. There is no token information. No supply schedule. No valuation. No investor list. No audit. No governance documentation. No sequencer roadmap. No bridge specification. No independent deployment history to inspect. The disclosure contains none of the things a forensic analyst would normally reach for first.

This is not a failure of the project. It is a description of its stage. GIWA is early. Very early. And early projects are, by definition, mostly caveats.

But the market rarely behaves as if early means empty. The market prices possibility. It front-runs delivery. It builds expectations on top of press releases, and then treats those expectations as though they were assets on a balance sheet. This is the environment in which a rumor about a leaked RPC endpoint can acquire enough momentum to force an official response — from a chain that, by its own account, does not yet have the thing that supposedly leaked.

You should sit with that contradiction. A project with no mainnet generated a security rumor serious enough to warrant a public denial. That means, at minimum, that enough people cared about GIWA to invent or spread a story about it. Attention arrived before the product. This is the normal ordering in a bull market. It is also the ordering that produces the most expensive mistakes.

I have watched this pattern repeat with mechanical regularity. In the aftermath of the 2018 Parity multisig failure, I spent four months inside the smart contracts of a major decentralized exchange, hunting integer overflows in atomic swap logic. I submitted three high-severity findings. The launch slipped. The release held. What I learned there was not a lesson about overflow arithmetic. It was a lesson about sequencing: theoretical elegance means nothing until someone verifies the code, and the market almost never waits for verification before it starts pricing.

GIWA is being priced. The verification has not happened yet. This article is an attempt to reason carefully about what can and cannot be concluded from a very small set of facts — and to resist the temptation to fill the gaps with narrative.

The Meta-Problem — A Denial Is Not a Disclosure

Before dissecting the technical surface, I want to make an honest accounting of what kind of document this is.

It is a defensive clarification. It is not a proactive disclosure. The distinction matters enormously for how you read it.

A proactive disclosure is written by someone who controls the narrative and wants you to know what they have built. It front-loads specifics because specifics are the point. A defensive clarification is written by someone who has lost control of a fragment of the narrative and wants to reclaim it. It rear-loads specifics — or omits them entirely — because the goal is containment, not education.

This document is containment. The team was responding to a claim. When you respond to a claim, you inherit the claim's frame. You end up denying the version of reality your opponent constructed, rather than presenting a reality of your own choosing. That is a structurally weaker position, and it is worth noticing when a well-resourced operation with a large exchange behind it finds itself in it.

The defensive nature tells us three things, with varying confidence.

First, the FUD had enough reach to require an official answer. A rumor that no one believes does not merit a public statement. The fact of the statement is itself evidence of the rumor's circulation. This is a moderately confident inference. I cannot measure the reach directly. I can only observe that the response occurred.

Second, the project believed a response was the better option than silence. In crypto, silence is a strategy. Many teams let rumors die on their own, on the theory that amplification is a losing game. GIWA chose to speak. That choice implies the team judged the rumor's trajectory to be rising, not falling.

Third, and most importantly for the forensic analysis that follows, the clarification drew a boundary. It specified which RPC did not leak. It did not specify which RPC exists. That boundary is the most interesting technical object in the entire disclosure, and I want to push on it until it either yields or snaps.

The Seam — "Mainnet RPC" Versus "RPC"

The clarification concerns the mainnet RPC. Read that again, slowly. The denial is scoped to the mainnet. It is not scoped to RPC endpoints in general.

The distinction is not hairsplitting. It is architecture.

Every functioning testnet has at least one RPC endpoint. Without one, nothing can connect. Wallets cannot read balances. Faucets cannot distribute funds. Block explorers cannot index state. Developer tooling cannot simulate transactions. The RPC is not an optional peripheral on a testnet. It is the load-bearing interface through which the entire test environment is accessed and observable by anyone the network admits.

So when a project says the mainnet RPC was never launched, in the context of a testnet-phase project, the reader is entitled to ask a precise follow-up: what RPC endpoints are live, who controls them, what authentication gates them, and what they expose.

I am not claiming a testnet RPC leaked. I have no on-chain evidence of that, and I will not manufacture it. What I am claiming is narrower and more defensible: the denial's scope creates an information boundary, and information boundaries in technical communications are almost always deliberate. Teams write scoped denials on purpose. The grammar of a denial is a design decision.

There are benign explanations. A scoped denial may simply be accuracy for its own sake — the team stating the precise thing that is true, no more. That is entirely plausible and, if true, is to the team's credit. Precision is rare and should be rewarded.

There are also less benign explanations. A broadly worded denial that turns out to be technically false is a liability. A narrowly worded denial is harder to falsify and easier to defend. A team with legal counsel and public-market exposure will be advised to scope its statements to what it can prove. That is rational behavior, and it is also the behavior that produces sentences like the one we are examining.

I cannot resolve which explanation is correct from the outside. What I can do is flag the seam and mark it for future reference. If, in six months, a testnet endpoint is disclosed to have been misconfigured during this period, the scoped denial will look very different in retrospect than it looks today. The purpose of forensic note-taking is not to indict. It is to preserve the ability to indict later, if the evidence warrants it.

Check the multisig. Always. And check the scope of the denial. Always.

Anatomy of an RPC Endpoint, Because the Word Is Doing Too Much Work

The term "RPC leak" gets thrown around as if it describes a single, obvious failure mode. It does not. RPC stands for Remote Procedure Call, and the endpoint is the interface through which wallets and applications talk to a node. The failure modes cluster, and the clusters have very different severity profiles.

There is the read-only exposure. A public, unauthenticated RPC that anyone can query. This is not a leak in any meaningful sense. It is a design choice, and most testnets adopt it deliberately to lower the barrier for developers. Calling this a leak is a category error, usually made by people who have never run a node.

There is the rate-limit and key exposure. Many RPC providers gate access behind API keys. If a key is embedded in client-side code, scraped from a public repository, or transmitted insecurely, it can be harvested and abused — usually to exhaust someone else's quota, occasionally to correlate activity. This is a real but bounded problem. It is an operational hygiene issue, not a protocol compromise.

There is the metadata exposure. RPC requests carry IP addresses, timestamps, and access patterns. A misconfigured endpoint that logs and exposes this metadata can deanonymize users or reveal the shape of a network's activity. This is genuinely serious for privacy-focused users, and it is the failure mode most often conflated with the loose phrase "RPC leak."

There is the administrative exposure. This is the catastrophic category. If an endpoint exposes administrative methods — node management, peer controls, state overrides — then the compromise is not about data. It is about control. This is the category where an attacker moves from observer to actor.

The phrase "RPC leak" does not tell you which of these occurred, if any occurred at all. It is a headline, not a diagnosis. A serious clarification would specify the category. This one does not. That omission is what keeps the ambiguity alive, and ambiguity in a security context is its own risk factor.

I will state the obvious because the obvious is often skipped: when a project issues a security clarification, source it to primary documentation, not to the headline that made the clarification necessary. The headline has already demonstrated that it compresses. Compression is where precision dies.

Every Testnet Has an Endpoint, and That Is the Whole Point

Let me be blunt about the baseline, because the baseline is where the rumor likely lives.

A testnet without a live RPC endpoint is not a testnet. It is a repository. The moment a chain is functional enough for developers to deploy contracts and for users to interact with them, an endpoint exists, and someone is operating it. Those endpoints are frequently operated centrally. On a testnet, that is expected and largely acceptable. Public testnets are, by design, open environments. Open environments have open doors.

This produces a specific kind of FUD. Someone discovers an exposed endpoint. They probe it. They find it responds. They conclude that a leak has occurred, when what has actually occurred is that a public testnet is public. The story then propagates through channels that cannot distinguish between "I found the front door" and "I found a way in."

The defensive response — ours is not live — is technically accurate if the endpoint in question belongs to the mainnet scope and the mainnet is not deployed. But it does not address the underlying curiosity, which is what exists on the testnet side. And because it does not address it, the curiosity persists.

There is a governance and operational lesson here that applies well beyond GIWA. Security communication should be exhaustive with respect to categories, even when it is minimal with respect to details. Saying "the mainnet RPC was never launched" invites the follow-up. Saying "the mainnet RPC was never launched; testnet endpoints are public by design, unauthenticated, isolated from production credentials, and contain no user data" closes the loop. The second sentence costs very little to write. Its absence is a choice.

I make this criticism with a degree of sympathy. Exchange-adjacent teams operate under legal review. Every sentence may pass through counsel before it ships. Counsel optimizes for defensibility, not for clarity, and defensible language is frequently scoped. But the analyst's job is to read what was written, not to imagine what might have been intended. And what was written leaves a door open.

The OP Stack Inheritance and the Sequencer Question

GIWA is built on the OP Stack. This is a deliberate and defensible engineering decision, and it comes with a fixed set of architectural inheritances — some of them features, some of them liabilities.

On the feature side, the OP Stack is mature. It is battle-tested across Base, OP Mainnet, Unichain, and Soneium. Deploying on it means deploying on a framework whose failure modes are documented, whose tooling is extensive, and whose ecosystem is interoperable. For a team whose comparative advantage is distribution rather than protocol engineering, this is the correct call. Building a rollup from scratch would be an act of ego, not engineering.

On the liability side, the OP Stack's default architecture includes a centralized sequencer. The sequencer is the node that orders and batches transactions before they are posted. In the default configuration, it is operated by a single entity. For a testnet, this is unremarkable. For a mainnet, it is the chain's primary centralization vector, and it is the vector that most users never think about.

This is where I want to slow down, because the sequencer deserves more attention than it typically gets.

A centralized sequencer can, in principle, reorder transactions, delay them, or censor them outright. It can extract maximal extractable value by front-running its own queue. It controls the ordering that determines who gets executed first. It is the difference between a chain that is neutral and a chain that is operated. Most users will never notice. Most users never notice a great many things.

For a chain operated by an exchange's parent company, the sequencer question is not academic. It is governance-adjacent. The entity that orders transactions is the entity that decides, in a mechanical sense, whose transactions exist. Trust in that entity is the actual security model, whatever the documentation says about fraud proofs and challenge windows.

I have been writing about this long enough to have watched a pattern harden. In 2026, I audited three protocols that billed themselves as autonomous agents managing crypto assets without human oversight. My engineering background let me decompile their core logic, and in two of them I found hardcoded backdoors that allowed developers to drain funds under conditions the whitepaper never mentioned. The lesson was not that autonomy is impossible. The lesson was that decentralized claims require decentralized proofs, and the proof is always in who holds the keys.

So the relevant question for GIWA is not "is it an L2?" It obviously is. The question is: who holds the keys to the sequencer, who holds the upgrade keys to the L1 contracts, and who can change the rules without asking anyone?

There is no answer in the current record. That is not an accusation. It is a data point. It is the thing to track.

One Second, and the Soft Confirmation Trap

Reports indicate a target of one-second block times, framed alongside EVM compatibility as the chain's headline performance claim.

One second is a capable number. It is faster than the two-second cadence of Base and OP Mainnet. Presenting it as a differentiator is a marketing decision rather than a technical argument, and I want to explain the gap between the two with some care.

In an Optimistic Rollup, there are two clocks that matter. The first is the block production clock — how quickly the sequencer proposes blocks. The second is the finality clock — how long until a transaction is economically irreversible, meaning how long until it is settled on Ethereum and the fraud-proof window has run.

One second is a block production clock. It is achievable. It is achievable on the software side without heroic engineering, because a rollup's sequencer is, at bottom, an ordering service, and ordering services can run fast. What one second does not tell you is how long a transaction is truly final. Finality in an Optimistic Rollup is bounded by the challenge window on Ethereum, and that window is measured in days, not seconds. No sequencer speed changes that.

The risk is that users conflate the two clocks. They see "one second" and hear "one-second finality." The transaction appears confirmed in their wallet in a second. Their balance updates in a second. The user interface renders a success state in a second. All of that is a soft confirmation — the sequencer's promise that it intends to include the transaction. It is a promise, not a settlement. It can, in the event of a sequencer reorg, be revoked.

This is not unique to GIWA. It is a structural property of the entire Optimistic class. But chains with fast block times market the fast clock and stay quiet about the slow one, and that asymmetry has real consequences for users who never learned the distinction.

I have calculated these asymmetries before. During the 2020 DeFi summer, I back-tested Uniswap V2 liquidity provision with Python scripts against 2019 and 2020 data and documented a roughly 40 percent average loss for liquidity providers in volatile pairs — a result that flatly contradicted the yield narratives circulating at the time. The mechanism there was impermanent loss. The mechanism here is confirmation ambiguity. Different mechanics, same structural lesson: the number on the marketing slide is the number that hides the most.

When GIWA ships, the interesting measurement will not be the target block time. It will be the deployed challenge window, the documented withdrawal delay, and the mechanism by which a user's balance on GIWA becomes a balance on Ethereum. Those three numbers describe the real experience. One second is a headline. The withdrawal delay is a fact.

The Phishing Surface — The Only Attack That Has Actually Been Confirmed

Here is the part of the disclosure that deserves the most attention and is receiving the least: the warning about impersonation scams.

Strip the FUD framing away and look at what the team actually told users. They said, in effect, that bad actors are presenting themselves as GIWA. That is a confirmed, present-tense, active threat. It is not speculative. It is not a rumor about an endpoint. It is a description of something happening now, to real users, with real consequences.

And it should be understood as a direct consequence of the project's attention profile. GIWA sits inside a compelling narrative: the largest Korean exchange building a chain, on a well-known framework, in a bull market, with a well-known absence of token information. That combination — strong brand, no token, high visibility — is precisely the combination that phishing operations optimize for. They do not need to hack a chain. They need a user to believe a fake site is the real one and to connect a wallet.

The mechanism of the attack is not technical sophistication. It is brand mimicry. A counterfeit domain. A fabricated airdrop page. A fake "claim" interface that requests a signature which grants a drainer permission to move assets. The chain's own RPC configuration is irrelevant to this attack. The attacker never touches the protocol. The attacker touches the user.

This is where the phrase "user error" does enormous damage, because it implies the user made a mistake they could have avoided with more care. Many of these drains are not avoidable by attentiveness alone. The user is asked to sign something that looks routine and that, in the course of normal DeFi activity, they have signed a hundred times before. The distinguishing signal is buried in the contents of the signature request, which most wallet interfaces render as an abstract string.

Signatures. Revoke permissions. Verify the domain. These are the mitigations, and they are adequate only if repeated until they become reflexive.

On-chain evidence never sleeps, and the drain transactions that result from these attacks will sit on the ledger forever, visible to anyone who cares to look. The victims are named by their addresses. The attackers are named by their flow. The pattern is legible. It is just not legible in advance, to a user holding a phone and deciding whether to click.

The Token Black Box

The disclosure contains no token information. Not a ticker. Not a supply. Not a schedule. Not a hint about whether one will exist.

That absence is itself information, and I want to be careful about how I characterize it. "No token mentioned" is a fact. "No token has been decided" is an inference. "A token is coming" is also an inference, and it is the one the market tends to make.

If a token exists — if there is a supply, an allocation, a vesting schedule — then the standard forensic questions apply with full force. How much is allocated to the team? To investors? To the community? What is the cliff structure? What is the unlock cadence? Who holds the multisig over the treasury, and how many signatures does it require? These are not hostile questions. They are the questions that determine whether a supply schedule is a mechanism of alignment or a mechanism of extraction, and the answers are only useful before the token trades, not after.

But I want to resist assuming a token is coming, because assuming so has become the default and the default is costly. Consider the counterexamples. Base has no token and has become the dominant exchange-affiliated L2. That absence has not impaired adoption; if anything, it has simplified the value-capture argument, because there is no token to dilute attention or to be priced on speculation.

A chain can capture value through fees, through sequencer revenue, through integration with an exchange's core business, without ever issuing a token. Whether that is GIWA's plan, I cannot know from the record. What I can say is that a project which has deliberately not released token information is not necessarily withholding it. It may simply not have one.

The market, however, will assume otherwise. The assumption of a future token is baked into how attention flows toward chains in this phase. Testnet activity functions as a proxy for a speculative position. Users interact with the testnet not because they need a testnet but because they believe interaction will be rewarded. That belief is not irrational given the industry's history. It is also not confirmed by anything GIWA has said.

Treat the assumption as an assumption. Do not confuse a hypothesis about a future event with a fact about the present. The present fact is that there is no token. Everything beyond that is a forecast, and forecasts about token events are the least reliable category of forecast in this industry.

Governance, Delegation, and the Illusion of Decentralization

Governance questions are premature for a testnet with no token. I am raising them anyway, because the answers take a long time to establish and the moment to establish them is before the incentives arrive.

In my experience reading governance systems, there is one pattern that repeats with tiresome regularity: delegation concentrates power, and it concentrates it faster in proportion to how much research is required to vote well. Users who cannot evaluate a proposal for themselves delegate to someone they believe can. That someone becomes a delegate for many people. The many-into-one flow looks like distributed participation — each user chose freely — and behaves like centralization, because a small number of delegates ends up determining outcomes for holders who never independently formed a view.

The nuance that the "decentralization" narrative typically skips is that low turnout is not evidence of apathy. It is evidence of a cost-benefit calculation. When the cost of understanding a proposal exceeds the expected value of the vote, rational holders delegate or abstain. The result is a system that is "decentralized" in form — anyone can participate — and concentrated in practice, because almost no one does.

For an exchange-affiliated chain, the concentration is compounded. The parent company already holds a privileged position. If a token is added and delegation becomes the norm, the plausible outcomes narrow further. There are ways to design against this — governance minimization, optional delegation, explicit design for abstention, transparent delegate incentives — but they require being designed deliberately, before the token exists, when the incentives that drive concentration have not yet arrived.

The best time to think about governance is when it does not matter yet. That is exactly the moment most teams spend on token mechanics instead.

DeFi on an Unlaunched Chain, and the Arbitrary Rates Problem

A related question is what DeFi on GIWA would even look like, and I want to use it to make a point that applies across the industry.

If GIWA is EVM compatible and part of the Superchain, then the expectation is that established DeFi protocols will deploy to it, and that lending markets will form. Those lending markets will inherit the standard interest rate models of the dominant protocols, and those models deserve far more skepticism than they receive.

I have argued for years that prevailing interest rate models are essentially arbitrary. They use a utilization-based curve — a piecewise function mapping borrowed fraction to rate — that is calibrated by intuition and governance vote rather than derived from observable market structure. The terms "optimal utilization" and "slope" are parameters someone chose. They are not measurements of anything. The market does not have supply and demand in the sense that a commodity market does; it has a curve someone drew, and participants live inside the curve.

On a chain with a smaller, newer user base, this arbitrariness compounds. The curves that work on a deep, liquid market behave poorly on a thin one. Rates swing on small flows. Liquidations cluster. The model, which assumes a certain shape of participation, is applied to a population that does not have that shape. The result is a system that appears mathematical and is actually tuned by hand.

None of this is a criticism of GIWA in particular. It is a criticism of the industry's habit of treating a chosen formula as a discovered law. It matters here because a new chain will inherit the formula along with everything else, and the formula will look like rigor while behaving like convention.

And when those rates misprice and liquidations cascade, the security assumptions of the L2 become load-bearing in a way they were never tested to be. Thin markets and automated liquidation are an unhappy pair.

Solvency Logic Applied to a Chain With No Assets

There is an instinct I have carried since 2022, and it is to apply solvency logic to any structure that holds user value. When Terra collapsed and the contagion moved into Celsius and FTX, I ran reserve-proof analyses on mid-tier exchanges, comparing reported user balances against on-chain holdings. One platform showed a shortfall of roughly 70 percent in BTC reserves. That number — a ratio — was the whole story. It did not require opinion. It required subtraction.

GIWA presents a difficulty for this instinct, and I want to be honest about it. There is nothing to reconcile yet. No user value, no reserves, no custody, no attestation. A chain in testnet has no balance sheet in the sense that matters to a solvency analyst.

What I can do is name the future reconciliation, so that it is pre-specified and cannot be moved later. When GIWA holds user value, the ratio to watch is the one between what the chain claims to hold and what the settlement layer actually contains. When it operates a sequencer, the ratio to watch is the one between stated decentralization and independent operators. When it issues a token, the ratio to watch is the one between supply created and supply genuinely distributed.

Ratios do not negotiate. That is their entire value. They give you a number that cannot be talked out of being true.

Contrarian — What the Bulls Got Right

I have spent most of this article pulling threads out of a denial. Now let me argue the other side, because a one-sided teardown is as unreliable as a one-sided pitch, and I would rather be accurate than emphatic.

First, the team's non-anonymity is a genuine and rare advantage. Dunamu is a real corporate entity with a regulated operating history behind it. The walk-away-with-the-faucet risk that plagues anonymous projects — the risk that a team disappears with funds — is structurally minimal here. In an industry where that risk is common, a named counterparty matters more than any performance claim. The trust that comes from a listed, regulated parent is not a substitute for audit, but it is not nothing, and pretending it is nothing would be dishonest.

Second, the disclosure is arguably good practice. In a market saturated with teams that either ignore rumors or amplify them for attention, a team that issues a scoped and accurate denial is doing something the industry under-supplies. I argued earlier that the scoping created an opening. That is true. It is also true that a vaguer denial would have been worse, and that saying nothing would have let a rumor harden into fact. The team chose precision over comfort. Precision has costs. It is still the better choice.

Third, the absence of a token may be a virtue. A chain that grows without issuing a token is not immune to speculation — nothing is — but it is disarmed of one of the most aggressive forms of incentive distortion. It has no supply to allocate to insiders, no vesting cliff to explain, no unlock schedule to defend. That discipline is not nothing.

Fourth, the Korean market is a genuine and underappreciated structural advantage. GIWA sits on top of the user base of the country's largest exchange. Distribution is the hardest problem in crypto and the easiest for a large exchange to solve. Base proved that an exchange-affiliated chain can become dominant; it did not prove that only Coinbase could do it. Upbit's user base is real, its deposits are real, and the friction reduction from having deposits and withdrawals native to a chain is a real product improvement — even if it is a distribution advantage rather than a technical one.

Where the bulls are wrong is not in their assessment of the advantages. It is in their treatment of the advantages as sufficient. None of the four points above produces a working chain. They produce a favorable starting position. The distance between a favorable starting position and a functioning ecosystem is where most projects die.

Takeaway

Watch the scope of the next denial.

That is the line I would draw from this episode. The useful thing about a scoped statement is that it becomes falsifiable over time. Right now, "the mainnet RPC was never launched" is true and uninformative. In six months, it will either remain true — in which case the ambiguity was incidental — or it will be replaced by a broader denial or a disclosure that requires re-reading the first one. Either way, the sentence we have will have earned its place in the record, and its scoping will be the reason.

The temptation in a bull market is to skip past the denials toward the promises. Promises are exciting and denials are not. But the denials are where the honest accounting hides, because a denial is a boundary a team has chosen to draw, and boundaries are where you learn what a team is willing to say. GIWA has told us what it is not. It has not told us what it is. That gap is the entire investment question, and it will not close because we want it to. It will close because someone ships code, deploys contracts, and lets the ledger say the rest.

Follow the hash, not the hype. The hash is not here yet. Watch for it, and read the fine print on the day it arrives.