Verus Discord Announcement
As you probably know, we have been quite busy dealing with yesterday’s attack on the Verus<->Ethereum Bridge. We are confident we have protected the network against any further compromise, stabilized the overall network operation, and can now take the time to provide some details that have yet to be published about the event. At this stage, we’ll describe what happened, how the compromise worked, and what the attackers had to do to execute it. We’ll also touch on planning towards recovery and what you can expect going forward, as we work towards re-enabling network features. First, a comment about what the attack was not. It was not a simple attack, not balance spoofing as in the Wormhole class of exploits and as claimed by Blockaid (we do appreciate their labeling of ETH exploiter addresses), and not something like a reentrancy bug in the Ethereum contracts. The attack was multi-step, well planned, and sophisticated, almost certainly aided by AI and demonstrating a deep understanding of what they could and could not do in the protocol. Funds used to carry out the exploit came from Tornado Cash on Ethereum and from a community faucet on Verus minutes before the exploit was executed. In both cases, they took precautions to hide the origin of requests, though we did get some evidence, which is still being investigated.
EXPLOIT TIMELINE Here is a basic timeline from address funding to exploit conclusion: May 17, 2026 11:50:59 AM , the Ethereum address 0x5aBb91B9c01A5Ed3aE762d32B236595B459D5777 was funded with 1 ETH via Tornado Cash in this transaction (https://etherscan.io/tx/0x84dc53d6705447ec6b4904bb905f9d78460de9bc671bef36ef79517d44e8ec86) May 18, 2026 12:46:11 AM , the hacker used verus.cx/dev/demos/faucet to receive 0.02 VRSC to the their address: RW9vEWisAvEsvtb9LrPRt4q7w8iDB3g6zd, which was used within 4 minutes to begin submitting 4 blank, invalid, export transactions for the ETH chain destination, which had no transfers included, but contained supplemental information outputs. This was the first part of the exploit, which required significant study or a very good AI to understand how to get the Verus chain to accept these blank exports and their supplemental output, because Verus considered them non-active. Exports, typically cross-chain exports, may also use a type of output called a “supplemental export output”, which may contain additional transfers that are bound to the original export via a hash in the export. Supplemental outputs can only be put on a transaction that has a matching primary export. Once they succeeded in getting the chain to accept a blank, otherwise inactive export with Verus as source and Ethereum as destination, that enabled them to put a supplemental output onto the same transaction. The supplemental output was handcrafted to be parseable in two possible ways without triggering errors if it was misread. It also contained specific data that matched the hash of the fraudulent transactions they wanted to execute.
Since it was not considered a primary export by the core PBaaS protocol, this was not seen by the daemon as active or malicious. Getting that transaction to be accepted and misinterpreted with the handcrafted information completed the preparation needed for the next steps of the exploit, which would ultimately target the Ethereum contract. Once these outputs were on the chain in the following transactions after initial funding: (https://explorer.verus.io/address/RW9vEWisAvEsvtb9LrPRt4q7w8iDB3g6zd), the attackers could have been stopped if someone sent legitimate transfers over the bridge. This is because they had gotten invalid, though inactive transactions accepted, miners and stakers would recognize that there were two threads of exports, even though one was invalid, and stop being able to construct blocks under the DeFi rules, due to the error condition. Unfortunately, they were not stopped, as there was no legitimate Ethereum-destined transaction posted during their attack window. The exploit transaction itself being posted into the contract is what ultimately stopped the chain from moving forward. In a move that seems to indicate the attackers were aware of the timing risk or trying to get faster cross-chain notarizations, they put 4 transactions that all had the handcrafted outputs, meaning only one could be used, onto the chain. It seems that these transactions were an effort to get cross-chain notarization to Ethereum to occur faster.
Once a cross chain notarization was posted to Ethereum that was far enough ahead to prove one of their outputs, they submitted a handcrafted cross-chain import to Ethereum. The submitted import presented their provable, hand crafted supplemental output because they knew that if a supplemental output was submitted in that way, along with the transfers that matched the hash, the Ethereum contract did not check the supplemental field and would parse the output as if it were an active export. Since it was an existing and provable output, this error in parsing caused the Ethereum contract to place their handcrafted values, including the hash of their drain transactions, into what it interpreted as a primary export, which was enough to get the transactions to pass. The supplemental output of Verus transaction https://explorer.verus.io/tx/f899e6984dc7c3d7737bbca5d87db3682de355743349d40396a5fc34b9f5a733 was used to impersonate a valid cross chain export by proving the handcrafted information in the supplemental output #1 of that transaction and it not being parsed as supplemental data, which would have been rejected. The transaction with the fraudulent transactions and the handcrafted output and proof is here: https://etherscan.io/tx/0x6990f01720f57fc515d0e976a0c4f8157e0a9529194c4c15d190e98d087eb321
Shortly after the contract accepted the fraudulent transactions, most nodes that were mining and staking hit an assert that was caused by seeing both the invalid exports and a real export at the same time and recognizing an invalid chain state. After this, there were no additional compromises possible, as the chain and any subsequent notarizations stopped advancing until we issued an oracle notification to disable DeFi. The oracle notification required an effort to get one block in with it, and once that happened, it succeeded in getting blocks moving again by bypassing the assert, which will only happen if DeFi is enabled. There was a chance that the assert could have happened before the attackers succeeded in getting the last notarization confirmed, which would have stopped the exploit, but that did not occur in time.
NEXT STEPS While many of us in the Verus Community have suffered as a result of this exploit, some quite significantly and most or all contributors included, the fact that it took a multi-step exploit of this level of sophistication to first setup and then get past the contract checks does not indicate that the core Verus protocol, DREAM application model, all of the work in progress, or even the core bridge technology is incapable of realizing the Verus vision. It means that we need to realize that with the state of AI, exploits have entered a new phase, harden against this and any other vulnerabilities we might find with additional auditing, and figure out how we can all move forward with confidence. We also need to address the elephant in the room of how a decentralized community can deal with such an event and develop a plan to address the funds losses in a way that we as a decentralized community without VCs can. That means addressing the bridge functionality first, then working together to repair the damage these attackers have done to our network and community.
We are working on an approach that I was able to share a bit about in today’s community meeting and that we will write up and share in an upcoming announcement. For now, we are focused on doing every part of what it takes to get a hardened upgrade out with a plan that gives our community and network a solid path forward. Thank you!