The $5.4M Signing Key Compromise in the Gravity Bridge Hack

On May 30, 2026, Gravity Bridge lost $5.4M when an attacker drained assets from its primary Ethereum contract. The attacker submitted unauthorized withdrawal requests that passed validation because they carried signatures generated from a compromised signing key. Monitoring firms Specter and PeckShield flagged the transactions within minutes, after which the Gravity team instructed validators to shut down their nodes and the bridge itself.

Background

Gravity Bridge connects Ethereum with multiple chains in the Cosmos ecosystem. Users lock tokens on Ethereum to receive equivalent minted tokens on a Cosmos chain, or they burn tokens on Cosmos to unlock the originals on Ethereum. The system depends on a group of validators who run orchestrator software to monitor events on both sides.

When a user burns assets on the Cosmos side, the orchestrators collect the details and produce a batch of transfer instructions. Validators then sign a message that attests to the burn. The Ethereum contract accepts these signatures, verifies that a sufficient threshold of known validators approved the message, and releases the locked funds to the designated recipient. This signature based authorization replaces the need for a direct blockchain link between Ethereum and Cosmos.

The validator set consists of operators who stake tokens as collateral. Their signatures are aggregated to meet a quorum, typically two thirds of the active set. The contract stores the current validator public keys and uses them to check the ECDSA recoveries on each submitted signature. Orchestrators also relay the resulting batches so the Cosmos side can update its internal ledger.

This architecture allows fast finality once signatures are collected, yet it creates a critical dependency on the operational security of every validator. A single private key that leaves the secure environment can allow an attacker to forge approvals for transfers that never occurred on the source chain. Gravity had operated for several years without a major breach, but the design still required every validator to protect its signing infrastructure against theft, malware, or insider access.

Large-scale asset drain triggers security alerts

On May 30, 2026, a series of large withdrawals quickly struck the Gravity Bridge Ethereum contract, drawing the attention of blockchain security firms PeckShieldAlert and on-chain analyst Specter. The stolen assets included USDC, WETH (ETH), USDT and PAXG, all of which were sent to addresses under the attacker's control, most notably 0x7B582033061b96cC3F9421e73a749ED7C62da1F9. These transactions did not involve exploiting any vulnerable custom logic or smart contract bug. Instead, each call to the contract submitted a batch payload accompanied by an array of signatures that were recognized as valid. Investigation later showed that the attacker had obtained the private signing key of at least one active validator. With this key, they could produce legitimate signatures for arbitrary batch data that falsely indicated burn events had occurred on the Cosmos side.

The contract's verification process for such batches was straightforward: it recovered signer addresses from the provided signatures, checked whether they matched active validators, counted the valid ones, and if the total met the quorum threshold, executed the transfers without verifying the burn events. The relevant logic can be summarized as follows:

function submitBatch(bytes[] calldata signatures, Batch calldata batch) external {
 bytes32 digest = keccak256(abi.encode(batch));
 uint validCount = 0;
 for (uint i = 0; i < signatures.length; i++) {
 address signer = recover(digest, signatures[i]);
 if (isActiveValidator(signer)) validCount++;
 }
 require(validCount >= quorumThreshold, "Insufficient signatures");
 executeTransfers(batch.recipients, batch.amounts);
}

function submitBatch(bytes[] calldata signatures, Batch calldata batch) external {
 bytes32 digest = keccak256(abi.encode(batch));
 uint validCount = 0;
 for (uint i = 0; i < signatures.length; i++) {
 address signer = recover(digest, signatures[i]);
 if (isActiveValidator(signer)) validCount++;
 }
 require(validCount >= quorumThreshold, "Insufficient signatures");
 executeTransfers(batch.recipients, batch.amounts);
}

By creating batches that listed their own recipient addresses and desired token amounts, and attaching forged signatures that were still valid from the contract's perspective, the attacker was able to push the validCount above the threshold and trigger direct transfers to themselves. The bridge architecture assumed that validator keys would remain secure, and once one was compromised, there were no additional safeguards such as proof validation, transaction rate limits, or anomaly detection to prevent malicious withdrawals. The contract operated exactly according to its intended design, with no flaw in the signature verification code.

The entire operation took place within just a few blocks. Shortly after, portions of the stolen funds were moved through exchange and swap services including ChangeNow and Binance. When the laundering was complete, the attacker still held roughly 2,102 ETH, valued at about 4.23 million US dollars at the time.

The Loot Emptied in One Sweep

The attacker withdrew four different assets from the Ethereum bridge contract, totaling approximately 5.4 million US dollars at the time of the theft. The haul included 4.3 million USDC, 274 ETH, 434,000 USDT, and 14.164 PAXG, all of which were moved in a single transaction to the address 0x7B582033061b96cC3F9421e73a749ED7C62da1F9 under the attacker's control. Large portions of the USDC and USDT were subsequently converted through the service ChangeNow, with some proceeds routed via Binance, while observers noted that about 2,102 ETH remained directly in the attacker's possession after the swaps were complete. Although the bridge contract retained its remaining locked assets, operations were paused to prevent any further withdrawals. The pause effectively halted bridging activity between Ethereum and the affected Cosmos chains, leaving users who had already locked assets unable to complete transfers to the other side until service resumed. Liquidity that depended on the Gravity Bridge for rebalancing between these ecosystems became temporarily stranded. No lending protocols or decentralized applications built on Gravity suffered immediate bad debt, and the bridge did not issue unbacked wrapped tokens, since the attack targeted the unlock side rather than the mint side. Nonetheless, the interruption caused delays for projects that regularly move value between Ethereum and Cosmos, prompting traders and liquidity providers to adjust strategies, and leading some transaction volume to shift toward alternative bridges during the downtime.

The progress of this case

The Gravity team published a brief statement on X on May 30, 2026 that read, "There was an unfortunate incident on Gravity. Validators should halt their validators and orchestrators while this incident is being investigated." They provided no additional technical details at the time and did not disclose whether the compromised key had been rotated or revoked. The bridge remained halted for the duration of the public reports while the team conducted its review.

There are no public records of negotiations with the attacker or any offer of compensation to affected users. A portion of the stolen funds that passed through centralized services may be subject to later freezes, yet the majority had already moved into privacy preserving routes.

Similar issues keep occurring

This incident is not an isolated case but part of a recurring pattern of bridge attacks in recent years. The root cause across these incidents consistently points to private keys leaving their intended secure boundaries, whether through compromised signing key (as in Gravity), stolen multisig keys (Ronin and Orbit), or cloud infrastructure exposures (Wasabi). These cases underscore a critical reality: even when on-chain logic is sound, the operational layer protecting keys remains the weakest link.

The core lesson is unmistakable, validator signing keys and administrative private keys must be treated with the same rigor as treasury cold storage. Bridge teams and any institution managing significant digital assets should adopt enterprise-grade wallet security and key management standards. Live signing keys should never reside on internet-facing servers; instead, they belong in hardened Hardware Security Modules (HSMs) or fully air-gapped environments that prevent raw private material from ever being exposed.

Web3 is entering a new stage, and the security of its infrastructure is of paramount importance.

For Cosmos-based validators, tools such as TMKMS can help isolate keys from node memory.A particularly effective approach is shifting to Threshold Signature Schemes (TSS) or Multi-Party Computation (MPC) architectures. These solutions distribute key shares across multiple independent parties so that no single entity ever holds a complete private key, requiring coordinated cooperation to produce a valid signature and dramatically raising the difficulty of compromise.Regular key rotation schedules — ideally every thirty days — combined with frequent revocation drills ensure teams can swiftly contain and replace a compromised key without major disruption. Many forward-looking organizations now implement institutional wallet architectures featuring MPC wallets, multi-signature approval policies (such as 2-of-3 or higher across geographically distributed signers), hardware-backed keys, and real-time transaction monitoring with automated circuit breakers.Defense-in-depth monitoring is equally vital. Systems should continuously watch for anomalies like unusually large withdrawals, previously unseen recipient addresses, or irregular signature patterns, triggering automatic pauses when suspicious activity appears. Validator and orchestrator servers must maintain the smallest possible attack surface through hardened operating systems, strict access controls, phishing-resistant authentication, and clear separation of duties. Comprehensive security audits and penetration testing covering the entire key management lifecycle have become essential rather than optional.For bridge operators and institutions today, the most urgent step is to perform a full audit of every location where signing keys are generated, stored, or used, then migrate away from vulnerable file-based keys toward hardware-backed and threshold-based solutions. In an era when institutions are increasingly responsible for crypto treasuries and cross-chain infrastructure, robust key management is no longer a technical detail, it is the foundation of operational resilience and long-term survival in the space.