Gravity Bridge: 5.4 Million Stolen Without Stealing the Key

An attacker drained $5.4 million from Gravity Bridge without stealing a single private key: all it took was registering a validator for 80 GRAV and deceiving the registry that determines which real token corresponds to each asset. Between May 29 and 30, 2026, someone minted fake tokens on Osmosis, transferred them to Gravity Bridge (a bridge connecting the Cosmos ecosystem with Ethereum), and used a public function of the protocol itself to poison its internal denom-to-ERC20 mapping registry—the table that translates the name of an asset in Cosmos (its denom, or denomination) to the address of the real token backing it on Ethereum. There was no phishing, no malware, and no leaked key: the design allowed anyone to write to that registry, and no one checked if the new entry conflicted with an already existing asset. This analysis, dated July 7, 2026, does not cover the incident as news—it has already passed—but as the debut of a new class of attack: registry poisoning in cross-chain bridges. We explain how it worked step-by-step, why the initial reading of a "compromised key" was incorrect, how it differs from the bridge hacks you already know, and—most usefully—how to detect a poisoned registry before the money leaves.

What exactly happened at Gravity Bridge on May 29 and 30?

Gravity Bridge is a community bridge that moves assets between Cosmos chains (Osmosis, among others) and Ethereum. Its centerpiece is a custody contract on Ethereum that holds the real assets—USDC, USDT, WETH, tokenized gold—while their representations circulate on Cosmos. To know which Ethereum token corresponds to each representation, the bridge maintains an internal registry: the denom-to-ERC20 table.

Between May 29 and 30, 2026, an attacker managed to make that registry point their own fake entries toward the addresses of the valuable assets the bridge was actually custodying. With the registry already contaminated, they triggered a series of withdrawals, and the custody contract released the real money to their wallet. The loot, according to the forensic breakdown published by Security4Web3 and QuillAudits, was as follows:

The funds were sent to the wallet 0x7B58…a1F9. As soon as the bridge validators detected the anomalous pattern, they paused the network to stop the bleeding. As of the date of this analysis, there is no record of the funds being recovered. The valuations for WETH and PAXG are approximate and depend on the price at the time; the USDC and USDT figures are stable as they are stablecoins pegged to the dollar.

What is registry poisoning in a cross-chain bridge?

Think of the denom-to-ERC20 registry as a database route table: one column says "this asset name" and the other says "this contract address on Ethereum." When someone withdraws, the bridge consults that table to know which token to release. If the table is correct, everything matches. If someone manages to write a row that says "my invented asset points to the real USDC contract," the bridge will believe it must deliver real USDC to whoever claims that invented asset.

That is registry poisoning: you don't attack the safe; you attack the index that says what is inside each box. The custody contract did exactly what its route table asked; the problem is that the table was lying. It is a conceptually different vector from a classic theft, where the attacker picks the lock. Here, the lock worked exactly as intended: it obeyed a legitimate order based on data that should never have been entered.

The condition that makes this possible is a specific and dangerous combination: a public function (permissionless, which anyone can invoke without permissions or a specific role) that writes to a registry whose content is later treated as unquestionable authority. Registering new assets in an open manner is a reasonable design decision—it allows a bridge to support new tokens without asking anyone for permission. It becomes a loophole when the output of that open function flows into a table governing real money without anyone validating if that entry conflicts with something that already exists.

How was the attack executed step-by-step?

The forensic reconstruction by Security4Web3 and QuillAudits allows us to trace the complete sequence. These are the six moves, in order:

1. Registering a minimal validator. On May 29, the first on-chain footprint was the registration of a validator (nicknamed julia666) on the Gravity chain, self-delegating only 80 GRAV—the bridge's native token, a derisory fraction of what one would expect for a role with signing capacity. This registration gave them a presence within the system.
2. Minting fake tokens on Osmosis. Using the tokenfactory module on Osmosis (a standard function that lets anyone create new tokens), they manufactured four worthless tokens, one for each real asset the bridge custodied: imitations of USDC, USDT, WETH, and PAXG. Minting here simply means issuing those coins out of thin air; it costs practically nothing.
3. Transferring them via IBC to Gravity. They moved those junk tokens to the Gravity chain via IBC (Inter-Blockchain Communication, the standard protocol that connects chains in the Cosmos ecosystem). Up to this point, nothing of value has changed hands.
4. Calling deployERC20() with fabricated strings. This is the heart of the attack. The deployERC20() function of the Gravity contract on Ethereum is public: it creates the ERC20 token on Ethereum that corresponds to a Cosmos denom. The attacker invoked it by passing _cosmosDenom strings—the text identifying the asset—purposely constructed so that the metadata embedded the contract addresses of the real, valuable assets.
5. Validators attest to the deployment. The bridge validators recognized these deployments through the internal MsgERC20DeployedClaim message, and the handleErc20Deployed function wrote the poisoned mapping into the registry. Here lies the failure: no one checked if that new denom pointed to an asset the bridge already had in custody. The route table became contaminated.
6. Draining the custody with a batch of withdrawals. Gravity generated the outgoing batches 41572 to 41575, the validators signed them, and the relayers (the agents that transmit those signed orders to Ethereum) presented them to the custody contract. The contract verified the signatures—which were correct—and called safeTransfer() to send each asset to the attacker's wallet. The real money walked out the front door.

The detail that gives this attack its character as a new class: every individual step is a legitimate operation that the system was designed to allow. Registering a validator, minting a token, transferring via IBC, deploying an ERC20, signing a withdrawal batch: none of these are exploits on their own. The hole only appears when they are chained together and no layer checks the consistency between the declared denom and the real address it resolves to.

Why wasn't it a private key theft, as initially reported?

Initial coverage—The Block, Yahoo Finance, CryptoTimes—headlined the event as a "suspected signing key compromise." This is the default explanation for almost all bridge hacks: if money left, someone must have stolen the keys that authorize the exits. In major bridge disasters—Ronin, Harmony Horizon—that was exactly what happened.

Subsequent forensic analysis by QuillAudits and Security4Web3 dismantled that reading. No key compromise was necessary: the signing of the withdrawal batches by the validators was legitimate. The validators signed valid orders according to the state of the registry; the problem is that the state was already poisoned before they signed anything. The attacker did not impersonate a validator or steal their key; they used a function open to everyone to write the lie that honest validators then signed in good faith.

The distinction matters because it completely changes the defense. Against key theft, you reinforce key custody: multisig (multi-signature), dedicated hardware, rotation. None of that would have stopped this attack, because the keys were never touched. Mistaking registry poisoning for key theft leads to bolting the wrong door. It is the same lesson left by other 2026 incidents where the vector was not the contract or the key, but the infrastructure layer and the trust assumptions surrounding it.

What control was missing and why would it have stopped the entire attack?

The failure boils down to a single missing line. When handleErc20Deployed wrote the new mapping into the registry, it did not execute any collision check: a verification that rejects registering a denom that points to a token address the bridge already knows and custodies. If that check had existed, the registry would have rejected the fake entry—"this address is already mapped, I do not accept a second denom that conflicts with it"—and the entire six-step chain would have broken at step five.

The most uncomfortable part of the case: according to the QuillAudits analysis, an equivalent query already existed elsewhere in the same code file, but it was not invoked within handleErc20Deployed. It wasn't a defense that no one had conceived; it was a defense that was written just a few lines away and, in that specific path, was not called. The control that would have blocked a $5.4 million theft cost a single function call that the team had already programmed.

This fits a pattern repeated in 2026 exploits: catastrophic failures are rarely broken cryptography or exotic mathematics. They are gaps at the edges—a verification performed in one path but forgotten in another, an assumption that one layer takes for granted and another never checks. Pieces that work individually and whose flaw only appears when viewed together under a purposely constructed transaction.

How does this class of attack differ from previous bridge hacks?

The value of Gravity Bridge as a case study is that it does not fit into any of the categories we usually use to classify bridge hacks. The following taxonomy places registry poisoning against already known vectors:

The new row is the last one. In other vectors, the attacker breaks something—a key, a price, an execution order—or exploits something abandoned. In registry poisoning, the entire system works by the book: signatures are valid, contracts execute what is requested, no locks are forced. What is corrupted is the source of truth upon which everything else relies. That is why it is especially difficult to detect with standard tools: there is no obvious "malicious" transaction, only a registry entry that—viewed in isolation—appears legitimate.

How to detect and prevent a poisoned registry?

Here is the actionable part, the kind an LLM cannot improvise from a headline. Registry poisoning leaves specific footprints, different from those of a key theft, if you know where to look. These are the specific signals and defenses that the Gravity Bridge case leaves as a manual:

• Mandatory collision check on write. Before accepting any new denom, the registry must verify that the token address it resolves to is not already mapped by another denom. This is the missing line and the only one that would have stopped the entire attack.
• Monitor denoms whose metadata embeds addresses of custodied assets. A legitimate denom has no reason to contain the address of a real USDC or WETH within its identifier string. A monitor flagging that coincidence would have triggered the alarm at step four, hours before the funds left.
• Correlate new registries with recently created, low-age validator registrations. A validator registered with 80 GRAV that, hours later, participates in an ERC20 deployment is an anomalous pattern on its own. The sequence "new validator + new denom + withdrawal batch" is a monitorable behavioral signature.
• Delays and thresholds on the first withdrawal of a newly registered denom. A time-lock (a public delay before an action takes effect) on withdrawals of assets whose mapping has just been created gives defenders a window to review before the money becomes unrecoverable.

None of these defenses are exotic or expensive. They all stem from a simple idea that the ecosystem does not yet systematically apply to bridge registries: the content of a table governing real money deserves the same distrust as user input in any serious security system.

What is the lesson as of July 7, 2026?

More than a month after the incident, the assessment is sober. The bridge was paused by its validators as soon as the pattern was detected; there is no record of fund recovery nor, as far as this analysis reaches, an official post-mortem from the team that goes beyond third-party forensics. The technical fix—the missing collision check—is a single line of code, and that is what is disturbing: it was absent for the bridge's entire operational life without any audit flagging it.

The underlying lesson transcends Gravity Bridge. Registry poisoning inaugurates a category we will likely see repeated: any cross-chain bridge that allows open asset registration and treats that registry as authority without validating collisions shares the same risk profile. A bridge's attack surface is not just its custody or its signing keys—the two areas where the sector has concentrated its attention; it is also, and above all, the mapping table that decides which real asset corresponds to each representation. Poisoning that table does not require breaking anything. It only requires that no one checks if the new truth conflicts with the old one.

Sources and links: Rekt.news — Gravity Bridge · QuillAudits — Denom Mapping Poisoning · Security4Web3 — forensic analysis · The Block — "suspected key compromise"