VerusCoin Ethereum Bridge Experiences Second Major Exploit in Two Months

On July 23rd, Verus-Ethereum Bridge saw $7.54 million in assets withdrawn, with every cryptographic signature validating as legitimate. (Blockaid report)

All notary proofs, state roots, and Merkle paths traced back to properly signed, authentic blocks. The underlying cryptographic mechanisms did not fail. (Sunsec analysis, Pyro insight)

The breakdown occurred elsewhere: No one questioned whether the withdrawal was actually backed by real funds. (Sunsec post)

Just two months prior, the same bridge had been compromised for $11.6 million, caused by an identical entry point and vulnerability. (Blockaid analysis)

After May’s incident, the team applied a patch and negotiated a bounty, resulting in most of the stolen crypto being returned. (QuillAudits statement, VerusCoin update)

Roughly two weeks after reopening, another attacker exploited a separate weakness within the same overall trust boundary. (Blockaid thread)

This time, there was no open communication, negotiation, or public response.

When a protocol confirms the authenticity of a withdrawal without verifying its economic backing, is it a bug or an intentional design choice?

Sources: Blockaid, Pyro, Sunsec, QuillAudits, VerusCoin, CertiK, PeckShield, SlowMist, Backward Labs, The Block, DefiLlama

Blockaid was first to highlight the incident.

Blockaid’s post stated: "Blockaid detected a VerusCoin Ethereum Bridge exploit on Ethereum. An attacker used the bridge import path to trigger unbacked Ethereum-side payouts, draining ~$7.54M in ETH, tBTC, USDC, USDT, EURC, MKR, and scrvUSD from bridge reserves."

In a follow-up, Blockaid linked this event back to the May exploit: same contract, entry point, and vulnerability type, although with a new attacker and different wallet. (Further Blockaid details)

PeckShield promptly confirmed the loss and observed that, unlike the previous case, the attacker was already routing funds into Tornado Cash. (PeckShield alert)

QuillAudits noted a crucial distinction: no signature or notary key was compromised. Instead, a fraudulent withdrawal was notarized as if it were genuine. (QuillAudits explanation)

Importantly, QuillAudits emphasized: the function patched after the May exploit, checkCCEValues, was not the source of this latest breach. The new vulnerability was distinct yet still related to the fundamental trust assumptions of the system. (QuillAudits follow-up)

SlowMist provided the most granular technical explanation: VerusProof.checkExportAndTransfers verified hashReserveTransfers against attacker-controlled serializedTransfers and source/destination IDs, but it did not enforce accounting checks for totalamounts, totalfees, totalburned, or CTxOut nValue. Nor did it ensure that referenced CCE outpoints contained sufficient value and assets to cover the claimed transfers. (SlowMist technical post)

Backward Labs released the only formal incident report: The bridge accepted an import with valid proof that authorized multi-asset reserve payouts, breaking the rule that Ethereum bridge reserves should only be released for fully-backed, properly proven source-chain reserve transfers. (Backward Labs report)

Verus did not issue any statement at the time of the exploit or in the days following.

The Block contacted the Verus team for comment, but there is no public record of a response. (The Block article)

When multiple security firms are able to reconstruct the exploit in detail before the project itself responds, it raises questions about the value of such silence.

The Proof Mechanism and Its Flaw

When transferring value from Verus to Ethereum, users submit receipts, not messages.

On Verus, this receipt is a CrossChainExport output, which commits to a specified set of transfers, hashed and recorded on-chain. (Pyro breakdown)

Notaries then confirm a state root containing the export, which is relayed to Ethereum. The bridge contract checks the signatures, reconstructs the Merkle path, and verifies inclusion in a notarized block.

On Verus (as in Bitcoin), anyone can embed arbitrary data in output scripts. An export is a specific byte pattern, and the contract checks the structure—not the authority: it verifies parsing, correct source/destination, hash match for serializedTransfers, and that an input spends the prior export’s transaction hash. (Pyro details)

If these conditions are met, checkExportAndTransfers succeeds and processTransactions executes the payouts. (SlowMist technicals, VerusBridge contract)

What the contract never checks is whether the export is economically supported.

There is no validation of totalamounts, totalfees, totalburned, or the actual nValue in the CTxOut. The receipt may be valid, but the bridge does not confirm any value is actually locked on-chain to back the withdrawal. (SlowMist analysis)

Because the attacker controlled both the transfer data and the hash, all checks were trivially satisfied.

Vulnerable Contract: 0x54e03a1682fd0bb065b669f6296f97028dcfd4ce

Bridge Contract: 0x71518580f36feceffe0721f06ba4703218cd7f63

The exploit steps were as follows:

1. Initial step: The attacker performed a legitimate 0.01 VRSC transfer via the bridge, creating the latest export and satisfying the check for linkage to the previous export. (Pyro walkthrough)
2. Crafted export: A new Verus transaction spent that output and included a custom export, committing to eight transfers, all directed to the attacker’s wallet. (QuillAudits description)
3. Notarization: Two real notarizations (block heights 4162938 and 4162957), signed by eleven notaries each, were submitted to Ethereum. (Pyro details)
4. Execution: The import submission provided valid proofs, roots, and hashes. All conditions passed, so the bridge released the funds. (Pyro details)

The May and July exploits were not identical at the code level: While checkCCEValues was targeted in May, and successfully patched, the underlying assumption that a matching hash equates to actual backing went unaddressed. (QuillAudits clarification, SlowMist post)

The protocol confirms a receipt exists and is included, but never verifies that the associated value was ever locked on Verus. (Backward Labs report, Sunsec analysis)

Twice now, the system has proven receipts; twice, it has not proven their economic substance.

Details of the July Attack

All the assets left in a single transaction, with the entire process publicly visible.

Attacker Wallet: 0xbda71b58cec0b1c20a8f87ccd52fa0679747855c

Loot Wallet: 0xcfd0a20703cd11e0b9f665e1c3f1ef989c142d54

Exploit Transaction: 0xa1f1e65c1cea4dba4ae439cd4dcdba6cc2dbda0ed1228e61f29ae9c9324eb099

The single exploit transaction transferred:

• 1,137.45 ETH
• 71.50 tBTC
• 149,275 USDC
• 92,784 scrvUSD
• 78,300 USDT
• 59.43 MKR
• 220,357 DAI
• 31,475 EURC

For DAI, the bridge drew against its MakerDAO position, minting 220,357 DAI to fulfill the withdrawal. (Sunsec technicals)

Funds began entering Tornado Cash about 90 minutes after the exploit. (Pyro timeline)

Before mixing, the attacker consolidated the tokens—converting tBTC, various stablecoins, MKR, and DAI into approximately 3,916 ETH, which was then laundered through Tornado Cash. (The Block article, PeckShield alert)

The attacker used escalating Tornado Cash deposits—beginning with 0.1 ETH, then 1 ETH, then 10 ETH, and ultimately a series of 100 ETH transfers, all sent in rapid succession. (Tornado Cash router activity)

By the time the wallet was rechecked, only about 0.09 ETH remained. (Loot wallet balance)

No attempts at freezing funds, exchange coordination, or public recovery addresses were reported.

In contrast, during the May event, the attacker returned 4,052.4 ETH and accepted a 25% bounty. (QuillAudits report)

There is no indication that a similar arrangement was offered or considered in July.

When laundering is completed before any negotiation can begin, a bounty offer is rendered moot.

A Tale of Two Responses

In May, Verus communicated actively.

VerusCoin directed users to Discord, with lead developer Mike Toutonghi providing updates. (VerusCoin Discord notice)

Bounty terms were made public: the community offered 1,350 ETH for the return of 4,052.4 ETH within 24 hours. (VerusCoin bounty offer)

By May 23rd, 4,052.4 ETH—about 75% of stolen funds—had been recovered. (VerusCoin statement)

By May 28th, recovered assets were converted into their original formats for reintegration. (VerusCoin update)

On July 8, roughly 1,192 ETH was transferred from the recovery address back to the bridge contract, as part of the v1.2.17 bridge restoration and recovery update. (Etherscan transaction, release notes) The remainder of May’s recovery (tBTC and USDC) was not included in this transfer.

The funds were returned to the same bridge contract, which had only been patched for the specific bug exploited in May. (QuillAudits report)

Fifteen days after this deposit, a new attacker exploited a different vector.

This time, there was no Discord post, no public thread, no bounty, no negotiation, and no acknowledgment from the team.

The Block once again reached out to Verus, with no public response recorded. (The Block article)

The lack of communication was notable. In May, the silence was a pause before action; in July, it appeared as simple inaction.

Although Verus was silent on social media, their GitHub activity continued: an urgent bridge restoration (v1.2.17) was released July 3, an opt-out vote for a bridge contract upgrade (v1.2.17-1) followed on July 12, and development continued across several repositories. (Release notes, v1.2.17-1 update)

DefiLlama data shows Verus had nearly $90 million in total value locked at the start of 2025; by late July 2026, this figure had fallen below $5 million.

Returning recovered assets to a contract with unresolved vulnerabilities is not a recovery plan—it is a display of confidence unsupported by action.

If recovered funds are redeposited into a system with the same unresolved risk, whose interests are actually being protected?

The Verus-Ethereum Bridge was not undone by cryptography, but by an unchecked assumption in its design.

Twice now, the contract has authenticated receipts without confirming their economic validity.

The first incident cost $11.6 million and was resolved publicly. (Sunsec analysis, VerusCoin update)

The second resulted in a $7.54 million loss and silence. (Blockaid report)

There were 66 days between the two exploits, and just 15 days between the partial fund return and the subsequent theft. (Etherscan transaction, exploit transaction) The vulnerability was never secret—it was simply left unresolved.

The bridge successfully verified every signature, state root, and proof required by its protocol, yet still released funds that were never secured on the source chain.

If future patches only address the specific functions exploited in the last incident, while ignoring the core assumption, how many incidents will it take before the fundamental invariant is revised rather than simply reacting to the latest exploit?