The most dangerous weakness in a cross-chain bridge is not always a stolen private key, a compromised validator or a broken cryptographic algorithm. Sometimes it is something more mundane: two pieces of software disagreeing about what a signed message actually says.
That appears to be the central failure behind the Wanchain bridge incident involving Cardano, BNB Chain and approximately 515.2 million NIGHT tokens. The tokens were removed from a Wanchain-controlled bridge treasury on Cardano in four transactions, creating an estimated loss of roughly $9 million to $10 million at prices reported around the incident.
NIGHT subsequently fell sharply as a large quantity of previously locked tokens entered circulation and selling pressure spread through Cardano’s decentralized exchanges.
The attack has been described in some headlines as a Cardano hack, a BNB Chain hack or even a breach of the Midnight Network. None of those descriptions is technically accurate based on the information currently available.
Cardano continued processing transactions normally. BNB Chain did not suffer a consensus failure. Midnight’s validators, protocol and core infrastructure were not compromised. The vulnerable component appears to have been Wanchain’s Cardano-side bridge logic—the infrastructure responsible for deciding when tokens locked on Cardano could legitimately be released.
A Bridge Failure Between Two Functioning Blockchains
Wanchain operates cross-chain infrastructure connecting networks that cannot natively verify one another’s state. Its bridge between Cardano and BNB Chain allowed NIGHT holders to move economic value between the two ecosystems.
NIGHT exists as a native asset on Cardano. When users wanted to move it to BNB Chain, the bridge used a conventional lock-and-mint process. Native NIGHT was deposited into a treasury contract on Cardano, while a corresponding bridged representation was created on BNB Chain.
When users moved in the opposite direction, the process was supposed to work in reverse. The bridged tokens on BNB Chain would be burned or otherwise removed from circulation, and Wanchain’s bridge nodes would produce an authorization allowing the corresponding native NIGHT to leave the Cardano treasury.
The bridge therefore depended on a simple economic promise: every bridged NIGHT token circulating on BNB Chain should be backed by NIGHT locked on Cardano.
The attacker did not need to break either blockchain. The target was the mechanism enforcing that promise.
Wanchain confirmed that NIGHT was withdrawn from the bridge contract on Cardano and temporarily made WanBridge unavailable. The company said it was investigating the incident and would provide a transparent update after completing its analysis.
At the time of publication, that full postmortem had not appeared.
The Preliminary Root Cause
Blockchain security company BlockSec has published the most detailed preliminary explanation of the exploit.
Its investigation points to a problem called non-injective signed-message encoding inside Wanchain’s TreasuryCheck validator, a Plutus V2 smart contract deployed on Cardano.
The TreasuryCheck validator had an important job. Before allowing NIGHT to leave the treasury, it needed to verify that the withdrawal had been authorized by Wanchain’s bridge node group.
That authorization took the form of a digital signature over transaction data. In principle, the signature was intended to bind together details such as the source-chain transaction, token information, recipient, amount, fees and other bridge parameters.
The problem was apparently not the signature itself. The signature was cryptographically valid.
The problem was how the contract assembled the information before verifying that signature.
According to BlockSec, the validator combined 14 variable-length fields by placing their raw byte representations directly beside one another. It did not consistently place separators between the fields, nor did it encode the length of each field.
This can make a collection of structured values ambiguous.
Imagine a system that signs two numbers by joining them together. The values “12” and “345” produce the combined message “12345.” But the values “1” and “2345” produce the same combined message.
The individual fields are different, yet the final string is identical.
A cryptographic signature cannot protect information that was ambiguously formatted before it was signed. The signature only proves that someone authorized the resulting bytes. It does not independently know where one field was supposed to end and the next was supposed to begin.
This is why the vulnerability is described as non-injective encoding. Multiple distinct sets of input values can map to the same encoded message.
One Authorization, Two Very Different Withdrawals
BlockSec traced the identifier used in one of the attack transactions to a legitimate transaction on BNB Chain.
That original transaction reportedly authorized the release of approximately 3,110 NIGHT. It appears to have been a normal bridge operation carrying a valid authorization from the bridge’s signing system.
The attacker allegedly rearranged or manipulated the boundaries between the encoded fields while preserving the same final byte sequence. Because the bytes being verified had not changed, the original signature remained valid.
The altered Cardano transaction, however, interpreted those bytes differently.
Instead of releasing roughly 3,110 NIGHT, the TreasuryCheck contract authorized the withdrawal of 203,001,692 NIGHT.
That represents an increase of approximately 65,000 times over the amount associated with the legitimate BNB Chain transaction.
The same general technique appears to have been used across four withdrawals. Together, they removed approximately 515.2 million NIGHT from the treasury over about eight minutes.
This was not a conventional replay attack in which the exact same transaction was simply submitted twice. It was more subtle. The attacker appears to have reused valid signed data while changing its semantic interpretation.
The contract saw a valid signature attached to a withdrawal request that satisfied its programmed checks. What it failed to establish was that the structured withdrawal request meant exactly the same thing that the bridge nodes had intended to authorize.
The Hash Function Was Not Broken
It is important to distinguish this failure from a cryptographic hash collision.
A hash collision occurs when two different inputs produce the same hash output despite being represented as different byte sequences. Finding a practical collision against a modern cryptographic hash function would be a major cryptographic breakthrough.
That is not what appears to have happened here.
In the Wanchain case, the two sets of structured fields could be converted into the same byte sequence before hashing. The hash function then received identical input and naturally generated an identical result.
The attacker did not defeat the hash. The bridge handed the hash function an ambiguous message.
The distinction matters because replacing the hash algorithm would not solve the underlying problem. SHA-3, SHA-256 or another secure function would all return the same output when given the same bytes.
The correct fix is unambiguous serialization.
Every field must have a clearly defined type, order and boundary. Variable-length values should include explicit length prefixes or be encoded through a canonical structured format such as CBOR. Cardano’s serialization tools already provide mechanisms that can represent Plutus data with clear boundaries.
BlockSec specifically noted that using structured serialization before hashing could prevent this form of field-splitting and signature reuse.
Why Cardano Was Not Hacked
The malicious withdrawals were executed on Cardano, and the tokens left a Cardano smart contract. That does not mean the Cardano protocol itself failed.
Cardano correctly executed the validator code deployed by Wanchain. The blockchain reached consensus, checked the transaction according to its rules and recorded the resulting state change.
The fault appears to have existed in the application-level contract logic.
This is comparable to a banking application approving an unauthorized payment because of a bug in its internal authorization system. The underlying operating system and database may be working exactly as designed, but the application has still made a disastrous decision.
The incident also does not currently indicate a general vulnerability in Plutus V2. Other Cardano applications are not automatically exposed simply because they use the same smart-contract platform.
The relevant question is whether any other Wanchain contracts reuse the same encoding pattern. The public Wanchain repository describes similar authorization contracts for fungible-token treasuries, token minting and NFT operations.
Until Wanchain publishes a complete scope assessment, users cannot assume that the risk was limited exclusively to NIGHT.
Why BNB Chain Was Involved
BNB Chain appears in the story because the reused authorization originated from a legitimate bridge transaction there.
The attacker needed authentic signed material. A real BNB Chain bridge transaction provided it.
But there is no evidence that BNB Chain accepted an invalid state transition, suffered a validator compromise or produced fraudulent consensus data. The BNB transaction was apparently legitimate for the relatively small NIGHT amount it represented.
The failure occurred when Wanchain’s Cardano validator interpreted the signed information differently from the system that generated it.
That is one of the fundamental dangers of cross-chain infrastructure. A bridge must translate state between networks with different transaction models, data formats and smart-contract environments.
BNB Chain follows an Ethereum-style account model and executes EVM contracts. Cardano uses an extended unspent transaction output model and Plutus validators. The bridge must preserve the precise meaning of an event while translating it between those architectures.
A signature is only useful when both sides agree on exactly what was signed.
Midnight’s Network and Token Supply Were Not Directly Compromised
The Midnight Foundation said the incident involved third-party bridge operations rather than the Midnight Network itself.
There is currently no indication that an attacker took control of Midnight validators, altered Midnight consensus or discovered a vulnerability in the network’s privacy technology.
The NIGHT token contract was not used to create hundreds of millions of new tokens. The attacker withdrew existing NIGHT that had already been locked in Wanchain’s Cardano treasury.
The distinction is technically important, but economically it offers limited comfort.
Tokens that had been immobilized as backing for bridged NIGHT became available to the attacker. A substantial amount was reportedly moved through Cardano trading venues, contributing to a price decline of more than 30% around the incident.
The total NIGHT supply may not have increased, but the liquid supply available to the market changed abruptly.
That can produce many of the same immediate effects as an unauthorized mint: dilution of available liquidity, collapsing prices and uncertainty about who ultimately bears the loss.
The Under-Collateralization Question
The largest unresolved issue is not simply how many tokens the attacker withdrew. It is what remains backing the bridged NIGHT circulating on BNB Chain.
The Cardano treasury existed to collateralize the cross-chain representation. Removing 515.2 million NIGHT potentially leaves a gap between tokens locked on Cardano and bridged claims outstanding elsewhere.
If the corresponding BNB Chain tokens had already been legitimately burned, part of the withdrawal might represent direct theft without leaving an equal amount of circulating bridged liabilities. But if the attacker used small legitimate burns to authorize massively inflated Cardano withdrawals, the bridge treasury could have lost far more collateral than was removed from circulation on BNB Chain.
That would leave the system under-collateralized.
Wanchain needs to publish a complete reserve reconciliation showing the amount of NIGHT still held on Cardano, the quantity of bridged NIGHT outstanding on BNB Chain and the liabilities associated with pending transactions.
Without those numbers, holders of bridged NIGHT cannot independently determine whether every token remains redeemable.
The response may require Wanchain to replace the missing collateral, negotiate a recovery with the attacker, obtain support from ecosystem partners or establish a claims process.
Simply redeploying the vulnerable contract would prevent further withdrawals. It would not repair the balance sheet created by the exploit.
The Uncomfortable Audit Question
The incident is especially significant because Wanchain’s Cardano bridge had undergone multiple security reviews.
Project Catalyst records show that 250,000 ADA was allocated for a second audit of the bridge. The project marked the external-auditor selection, first code review, second review and final audit as completed. Wanchain’s proposal also stated that the bridge had been audited before its original launch.
An exploit after an audit does not automatically mean the auditors were negligent.
The vulnerable code may have been modified after the review. The NIGHT integration may have introduced new data formats. The deployed bytecode may have differed from the reviewed repository. The audit scope may have excluded off-chain message construction or the exact interaction between BNB Chain and Cardano.
It is also possible that the ambiguous encoding existed in the reviewed code but was not identified.
Only the audit reports, reviewed commit hashes and deployment records can resolve that question.
Wanchain’s postmortem should identify the precise vulnerable code version, when it was deployed, whether it was included in either audit and whether recommended changes were fully implemented.
Anything less would leave the most important governance question unanswered.
What Wanchain Must Fix Before Reopening
A safe restart requires more than removing NIGHT from the bridge interface.
The TreasuryCheck message format must be replaced with canonical serialization that preserves the type and length of every field. The new contract should use domain separation so that a signature created for one contract, network, token or action cannot be accepted in another context.
Bridge authorizations should bind themselves to the source-chain identifier, destination chain, contract version, token policy, exact amount, recipient, nonce and expiry. Every identifier should be consumed only once.
Wanchain must also examine its other Cardano validators for the same concatenation pattern. If TreasuryCheck, MintCheck, NFTTreasuryCheck or related contracts share utility code, the vulnerability may have a wider theoretical scope even when no additional exploitation has been observed.
The bridge node group’s signing software must be reviewed alongside the on-chain contracts. Security depends on both sides producing and interpreting exactly the same canonical message.
Finally, the project needs monitoring capable of stopping anomalous withdrawals. A request to release 203 million NIGHT when the corresponding source-chain event represented approximately 3,110 NIGHT should have triggered an automatic circuit breaker, regardless of whether the signature passed.
Cryptographic authorization should not be the only defense against economically impossible behavior.
A Bridge Can Be Decentralized and Still Fail Centrally
Wanchain describes WanBridge as decentralized and non-custodial because no conventional company-controlled wallet manually approves every transfer. Bridge nodes use distributed signing mechanisms, while smart contracts hold and release assets.
The NIGHT incident shows the limits of those labels.
A bridge contract can be non-custodial from the user’s perspective while still becoming a concentrated pool of collateral. It can use decentralized signers while depending on one shared interpretation of a message format. It can avoid a single private key while retaining a single vulnerable verification path.
Decentralization protects against certain failures. It does not automatically prevent software bugs.
The Wanchain exploit appears to have bypassed a sophisticated signing network without compromising any of its signers. The attacker did not need control of the authorization system because the same authorization could be made to mean two different things.
That is a more troubling failure than a simple key leak. Keys can be rotated. Ambiguous protocol semantics can remain unnoticed for years.
The Preliminary Verdict
The leading explanation for the Wanchain NIGHT exploit is now technically coherent and supported by on-chain analysis, but it remains preliminary until Wanchain publishes its own postmortem.
Approximately 515.2 million NIGHT left the Cardano-side bridge treasury in four rapid withdrawals. At least one transaction appears to have reused a legitimate bridge signature associated with a much smaller BNB Chain transfer.
The suspected root cause was raw concatenation of 14 variable-length fields without sufficient boundaries. That allowed different withdrawal parameters to produce the same signed bytes, enabling a valid signature to authorize a transaction the signers never intended.
Cardano was not compromised. BNB Chain was not compromised. Midnight was not compromised.
The bridge between them was.
That distinction matters for technical accuracy, but it does not reduce the seriousness of the failure. Cross-chain bridges exist to preserve value while translating information between incompatible systems. When the translation layer cannot distinguish a 3,110-token withdrawal from a 203-million-token withdrawal, the entire collateral model collapses.
The next test for Wanchain is no longer whether it can identify the flawed encoding. BlockSec has already presented a credible answer.
The real test is whether Wanchain can account for every missing NIGHT token, restore the bridge’s backing, prove that related contracts are safe and explain how a vulnerability this fundamental survived development, deployment and multiple rounds of auditing.