https://docs.google.com/document/d/1R5kxmTa01gHJ5V7XdjyFphG_q5V02mtkyK7lOR6lV3w/edit?tab=t.0This is from verus team in discord.
AI-assisted security exploits have fundamentally and irreversibly changed the entire IT landscape that we have known to date. The first half of 2026 alone has already broken previous records for highest number of cryptocurrency hacks, with verified losses exceeding $1 billion. Our experience with recent exploits on the Ethereum bridge along with a recent explosion of AI-assisted exploits across a range of platforms and systems make clear that we have entered a new phase of AI’s impact on infrastructure. Public protocols, systems, and implementations of anything worth protecting must now and forever withstand continuous, low-latency adversarial analysis and probing by hybrid AI/human black hats, making a cryptographic foundation the best hope for secure, scalable protocols of the future.
While Verus PBaaS does have such a cryptographic foundation, two back to back zero day exploits targeting the Ethereum bridge have made it clear that we have failed to perfectly match the PBaaS protocol’s BTC-style serialization (referred to as PBaaS serialization going forward), signatures, and cryptographic proofs in the context of Solidity and Ethereum. Although the second attack was different than the first in significant ways, the common concept in both was an asymmetry between PBaaS serialization and the Ethereum contract’s parsing of the data.
To understand how the recent exploit was executed and how it differs from the first one, it’s helpful to first consider the Ethereum bridge’s interaction with PBaaS and how it works to prove that an exact, validated export transaction exists on Verus to match an import submission that releases the corresponding transfers.
The Ethereum contract connection is an EVM-tailored, Solidity subset of the PBaaS cross-chain protocol that:
Communicates data based on PBaaS serialization,
Uses Ethereum hash types and minor variations to account for the Ethereum model differences and simplify the EVM notarization and proof verification requirements to a point where it is reasonable to implement in a contract, and
Is based on a cryptographically provable foundation, though it depends on equivalence in data processing on both sides of a connection.
As a protocol, the data itself determines behavior, and the assumption for the data serialization model is that all nodes, or in this case, the bridgekeeper+contract, which behaves together as a gateway node, will see the same objects from the same data as a Verus node
Original PBaaS requirements for a provable cross-chain protocol were:
Miners and stakers enter and agree on cryptographic notarizations and proof roots as a basis for cross-chain export/import proofs
Witnesses attest when they witness valid, agreed notarizations that pass their own verification checks
A defined threshold of multiple, agreeing, witnessed notarizations leads to a confirmed notarization, which, among other things, contains a “proof root” that can be used to mathematically prove a transaction or some specific data is valid on the other chain
Once an export transaction is cryptographically proven to be valid on the source chain targeting the destination chain, the destination chain can know that the source chain verified the transaction and proceed to process the corresponding import
At no time do miners, stakers, or witnesses have control over funds or approval of specific funds transfers, rather as long as both sides interpret all data equivalently, proven imports can be processed non-custodially with confidence
While the requirements listed in #3 remain valid, the fundamental assumption that was in error was that it was a reasonable task to succeed at implementing full compatibility and symmetry with BTC-style serialization and deserialization in custom, optimized solidity code without a compatibility error, if reviewed by multiple humans and AIs after the fact.
Given that background, let’s look at what exactly happened in this last exploit. Let’s start by considering the things that need to happen for an export/import from Verus to Ethereum to be correctly verified and processed:
One or more reserve transfers are entered by users onto Verus
An export, essentially a bundle of reserve transfers targeting a common destination is rolled up, submitted, and verified along with all source funds onto the Verus chain
The notarization process moves forward until a confirmed notarization with a proof root of a block at or after the source export is posted onto Verus
The confirmed notarization from the source chain is posted to the destination contract, which verifies it
#3 and #4 happen again to get a final confirmation and achieve a confirmed notarization in the contract, and
The export in question is proven according to the proof root in the confirmed notarization in the contract
After #6, reserve transfers are processed and funds are released
In this recent exploit, #1 and #2 were bypassed, as the attackers did not prove the existence of any export on the Verus chain. Instead, they discovered a subtle difference in the way that PBaaS serialization processed the data for a cross-chain notarization vs. the way the contracts did so. Specifically, when deserializing a notarization with proof roots, those proof roots are serialized one after the other in the data stream. When they are put into memory, they are stored in a data type called a map, which stores a unique key and its associated value for each entry. When deserializing, if there are two entries for the same key, something that would never be written by the daemon, an attempt to add the second entry is ignored and leaves the first entry intact. The contract behaves differently and overwrites the first stored root by the second when encountered, leaving a different proof root in memory, one that the daemon never considered when verifying the proof root that was there. The daemon would not create a notarization with two entries in the data stream when serializing, and it ignored the presence of a second one, which was added there in custom serialization code by the attacker.
They first posted a notarization to Verus that contained the extra data. Since PBaaS deserialization ignored that data, the deserialized notarization was correct and signed by witnesses. The attackers then submitted signed notarizations to the contract until one of the notarizations they created was confirmed. Since they were able to get the contract to read the same data and interpret a different proof root, the Merkle Mountain Range represented by the proof root that the contract saw was their own and contained an export that did not actually exist on Verus or anywhere else, which the contract accepted as authentic because it was proven against the proof root that it had stored over the real one when it deserialized the notarization. No public analysis we have seen anywhere, including by auditing companies who claimed to describe the exploit, even when they had the benefit of the actual exploit data to analyze has described these critical details, which are what actually describe the exploit. The attackers did a few other interesting things that were not required to execute the exploit, but demonstrate the likelihood of a frontier AI model or extreme talent being involved. A number of us believe their footprint looks different than the first exploit as well.
The first exploit differed in a few important ways. It did not attempt to attack the notarization system’s deserialization, but instead worked to put an output onto Verus that could be proven by real notarizations and be interpreted by the contract as a completely different output type than what the daemon considered it to be. The second exploit added unused data to a notarization output, targeting a much more subtle difference in deserialization by the contract than flags or any other indicator, which would no longer have worked. They found a semantic difference in the way that a map was deserialized, a difference which was missed in the initial work and multiple subsequent reviews.
While we believe this was the last asymmetry between the daemon and contract’s processing of data that should ever occur, our failure to prevent the second exploit shows that even after careful dev work followed by multiple human and human/AI reviewers, we missed something and did not achieve full symmetry in Solidity with PBaaS serialization for every adversarial case.
The most useful lesson we believe we must take from this event is that no matter how confident we end up being that this is the last occurrence of a difference in processing between Solidity and native development environments, we need a different, complementary security safeguard entirely as braces to the belt of the protocol that is independent of the contract’s interpretation and can handle discrepancies between the contracts and PBaaS of any kind. With such an additional safeguard in place and given time with use and no exploits, we can have confidence that even if we did have another unexpected asymmetry in PBaaS processing, only funds that have real funded exports on the Verus chain, something that has been a consistent invariant throughout the lifetime of PBaaS, should ever be released. This safeguard, different than, but inspired by brainstorming started by u/Munty, is designed to address any kind of difference-based exploit, and would have prevented both prior exploits from extracting funds, even before their asymmetries were fixed.
The new security safeguard is based on the fact that during both exploits, the exports accepted by the contract were never considered exports by Verus and not even seen by anyone who would check via Verus RPC APIs. Unfortunately, the RPC API is not directly available to contract code at all. Therefore, the solution we are implementing does the following:
Fix and further review with latest learning all known issues with symmetry. Theoretically, after that, we should have a complete fix independent of the extra security layer described in #2 and #3, and it will provide an approach with defense in depth
Process imports as they are currently processed, and instead of releasing funds, have an additional “funds release” period, where one of two things can happen to release funds:
A majority of witnesses can sign and say that they witness the identical export being processed as valid on the Verus chain via RPC. The key here is that this provides witnesses and anyone on the network, an easy way to check correctness directly from the PBaaS protocol, in addition to and separate from a cross-chain, cryptographic proof
A delay (8 or 12 hours), the duration of which is still TBD passes and nothing has been done to stop payout processing. This delay can be different for witness approved vs. witness unapproved imports.
As a result of #1 and #2, if something does ever manage to fool the contract to attempt to process an export that isn’t actually sent from the Verus chain, for one reason or another, the funds release period will provide assurance that the import is always backed by a matching, properly validated export on Verus and that a question about that being true will result in adequate time to stop import processing if necessary and fix any potential issue
There’s been a lot of discussion on the channels about how we can recover from this. Core contributors, me included still believe in what we are doing, and due to real support and backbone shown by u/Consilience and Valu to step up and help the foundation and project get through this time, we are moving forward with a belief that we can fully secure the bridge, finish releasing the advanced DREAM capabilities, get the Fiat on/off ramp out and into use, and enable apps that can drive real usage of large numbers of users to be released.
First thing we have to do is finish securing the bridge as described and accounting for the exploit losses. To account for losses, we must make the chain reflect the reality of the currencies that no longer exist. We plan to do this using the same technical approach to cleanup as last time, but in this case, we will be replacing 99.9% of currency lost in this exploit with usage-based restitution currency that will earn from usage in the same way as we intended for the first exploit, leaving a total of more to cover. After that, we and everyone who has an idea and way to execute can help the network grow with app-based usage, new Verus P2P gift cards, soon to be released in Verus mobile, and the fiat on/off-ramp enabling easy integration of payments, rewards, donations, P2P money transfers, and now multi-currency and ID gift cards into DREAM apps, driving further usage and helping the project and network recover and grow.
I’d also like to express my personal gratitude and hope you will too to u/Consilience and Valu for stepping in at this moment and offering critical support that can provide crucial support to get all of us through this difficult time. In spite of their own significant losses, Valu has pledged the following support and donations with a request that anyone who wants to see a full recovery, please consider matching in any way you can. Valu intends to:
Donate 0.1% of all lost funds to the network, preventing the zeroing out of baskets that would permanently disable them rather than greatly reduce their liquidity and enable their continued use for bridging or future revival.
Keep their 20K matching USD core funding in place and accelerate donations intended for >1 year from now to the next three months as well, donating an additional matching 30K $ per month during the next 3 months to cover core infrastructure costs and unexpected foundation contributor needs. That means that Valu would hope the rest of the community can match these donations collectively, and assuming we get reasonable matching in Verus or other currencies, core contributors should be able to stay on track during the expected liquidity drought, get the Fiat on/off ramp released, and enable release or near-release of at least one high potential app.
Commit to provide at least $50K of on-chain USDC liquidity for USDC fiat on/off ramp, and look at requirements for bridge converters to help people smoothly enter, exit, and move just as easily from bank to bank as around the Verus PBaaS ecosystem.
I personally appreciate these donations and their shared commitment, along with every contributor that either donates towards or puts time and effort into our long term collective success. Thank you.
I want to take a moment to talk about ongoing security work as well. I’ve seen discussion on the Discord about commissioning an “official audit” and claims that core people are against an audit or have been. I want to make it clear that no one, definitely not me, is against an audit. We all want the network to be absolutely secure as the AI Age evolves. The challenge is that existing funds critical to maintaining and securing the network by supporting developers, security researchers, dev/rel/ops, opsec, admin and other core contributors have always been stretched thin. No one has yet solved the problem of ensuring that those core contributors can continue their work as they choose to contribute while someone donates enough to cover an audit. That does not mean that we don’t have auditing from people, some of whom are likely better than most people we’d be likely to get on an audit. It does mean that until people donate enough to support an official audit, that we will not have the stamp that comes with one.
Auditing salespeople have so far come to us with a pitch, a price, no initial understanding of Verus, and a record that typically includes either few customers or exploits on their audited systems as well. Top auditing companies incorrectly described the most recent exploit when the entire exploit was public for all to analyze with all information in-hand. If we had the available funds for that and covering the basics, should we commission a corporate audit? Sure. Does it provide more real security than having experienced AI-assisted developers and researchers maximizing the help we get for resources we have? Not in my opinion or the opinion of most people investing time and money building on Verus and aware of the ongoing work. The security researchers who are helping us have each come to the project with findings that led to meaningful hardening, and the level of audit happening with people who are helping right now allows those of us building in or on Verus to have more confidence than trading the people and help we currently have plus more funds we don’t to a company that may or may not do a decent job working with core contributors who we’d still need to implement real improvements to actual security in the time they are engaged.
As we focus even more resources on work to further harden the network and implement additional security on the bridge, we will release updates anytime we meaningfully improve hardening. That means we may have 2 or more wallet updates before contracts are ready for upgrade. If we release an upgrade before the contracts are ready, it is for security. Please upgrade as early as you can during this time. We will do our best not to spam updates and balance that with the hardening and digging we are actively focusing on presently.
The last of the daemon releases will include preparations and details for the cleanup timing and contract upgrade votes. After we have gone through this work, deeper reviews, and completed the new Ethereum bridge security enhancement, we will describe and execute network cleanup transactions, re-enable DeFi, re-enable the bridge, get the restitution currency distributed, and work towards the Fiat on/off ramp, app releases, and launches that people have in progress.
