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.

Bitcoin’s most important disputes rarely begin with price. They begin with a deceptively simple question about what the network is allowed to become.

BIP-110, a proposal to temporarily restrict the amount and type of non-financial data stored in Bitcoin transactions, has turned that question into the protocol’s most contentious governance fight in years. Supporters argue that images, tokens and other arbitrary data impose permanent costs on node operators while distracting Bitcoin from its monetary mission. Opponents warn that policing transaction content at the consensus level would damage neutrality, restrict future upgrades and risk splitting the network.

As the proposal approaches its activation window, the practical verdict appears increasingly clear. Miner signaling has remained below roughly 1%, major pools have declined to support it and prominent Bitcoin figures including Michael Saylor, Adam Back, Jameson Lopp and David Bailey have publicly opposed the plan.

BIP-110 may be losing the activation battle. The ideological conflict behind it is not going away.

From an OP_RETURN Dispute to a Consensus Fight

The origins of BIP-110 can be traced to a wider argument over Bitcoin Core version 30 and its handling of OP_RETURN, a transaction output commonly used to attach small amounts of data to the blockchain.

Bitcoin Core had historically applied a default relay-policy limit of approximately 80 bytes to OP_RETURN data. Version 30 relaxed that policy substantially, effectively allowing larger data-carrying transactions to move through nodes running the standard configuration.

That change did not alter Bitcoin’s consensus rules. It did not make previously invalid transactions valid. It changed which already-valid transactions Bitcoin Core nodes would normally relay through their mempools.

The distinction between policy and consensus is central to the current controversy.

Policy determines which transactions an individual node chooses to relay or which transactions a miner chooses to include. Different nodes can maintain different policies while still agreeing on the same blockchain.

Consensus determines whether a block is valid. When consensus rules change, nodes enforcing different rules can permanently disagree over which chain represents Bitcoin.

BIP-110 attempts to move the arbitrary-data dispute from the policy layer into consensus. Transactions that are valid under current Bitcoin rules could become invalid to nodes running the proposal.

That escalation is precisely what supporters consider necessary—and what opponents consider dangerous.

What BIP-110 Would Actually Change

Known as the Reduced Data Temporary Softfork, BIP-110 proposes a one-year restriction on several methods used to embed data inside Bitcoin transactions.

The proposal would restore an 83-byte consensus limit for OP_RETURN outputs, restrict many data pushes and witness items larger than 256 bytes, and impose additional limits on certain Taproot structures. It would also temporarily disable several currently unused or rarely used scripting mechanisms that supporters believe can be exploited for data storage.

The proposal is therefore broader than a simple attempt to stop oversized OP_RETURN messages. It affects multiple transaction structures, including some that could become useful for future Bitcoin upgrades or advanced contracting systems.

Coins created before activation would be grandfathered, reducing the risk that existing funds could suddenly become unspendable. The restrictions would automatically expire after approximately one year unless a new proposal extended or replaced them.

Supporters present this temporary design as a controlled intervention rather than a permanent redesign. The network would gain time to reduce abusive data usage, observe the effects and consider a more refined long-term solution.

Critics argue that a temporary consensus rule is still a consensus rule. Even if it expires, it can create incompatible chains, disrupt applications and establish a precedent for invalidating transactions based on how participants interpret their purpose.

The Case for Keeping Bitcoin Focused on Money

The strongest argument for BIP-110 is economic rather than cultural.

When a miner includes a data-heavy transaction, the miner receives a fee once. Every full node may then be required to download, validate and store information associated with that transaction for years.

BIP-110 supporters describe this as an externality. The person embedding the data pays the miner, but does not fully compensate the thousands of node operators carrying the long-term infrastructure burden.

They also reject the idea that the fee market automatically solves the problem. A market for permanent, globally replicated data storage is not necessarily compatible with a market designed to prioritize financial transactions. Wealthy inscription users can compete with ordinary payments for limited block space, potentially raising fees for people trying to use Bitcoin as money.

The proposal’s authors argue that Bitcoin should not become a general-purpose database. Images, documents and token metadata can be stored through specialized systems such as IPFS, BitTorrent, Nostr or conventional cloud infrastructure. Bitcoin’s scarce base-layer capacity, in their view, should remain focused on transferring and securing value.

Luke Dashjr, a longtime Bitcoin developer and a leading supporter of restrictive transaction policies, has defended this monetary-first interpretation. Ocean, the mining pool associated with Dashjr, produced some of the earliest blocks signaling support for BIP-110.

For its supporters, the proposal is not censorship. It is resource management.

Why Michael Saylor Opposes BIP-110

Michael Saylor’s intervention significantly raised the profile of the dispute.

The Strategy executive chairman acknowledged that many Bitcoiners he respects support the proposal and that concerns about arbitrary data are legitimate. His objection is directed at the proposed cure.

Saylor argues that BIP-110 transforms a disagreement about relay policy, mining policy and market incentives into a dispute over transaction validity. In his view, consensus should not be used to settle a cultural argument about which fee-paying transactions are desirable.

He escalated his opposition by publishing an extensive list of 110 objections to the proposal. His concerns include the complexity of introducing seven new restrictions, the potential effect on future scripting upgrades, the possibility of incompatible implementations and the danger of attempting activation without overwhelming agreement.

Saylor also objected to the proposal’s 55% miner-signaling threshold. Conventional Bitcoin soft-fork deployments have often targeted much higher levels of readiness because even a technically backward-compatible change can become dangerous when important participants do not enforce the same rules.

His broader position is that Bitcoin’s resistance to change is a security feature. He described hard consensus as the network’s “immune system,” arguing that controversial ideas should fail before an attempted improvement causes greater damage than the original problem.

Saylor’s influence does not give him formal authority over Bitcoin. There is no board of directors that can approve or reject a protocol change. Nevertheless, his public opposition matters because Strategy is one of the largest institutional Bitcoin holders and Saylor has become a central voice in corporate Bitcoin adoption.

His message to institutions is straightforward: Bitcoin’s credibility depends on predictable rules, not frequent intervention.

Adam Back, Jameson Lopp and David Bailey Join the Opposition

Saylor is not alone.

Blockstream co-founder Adam Back has said the network has effectively and “robustly rejected” BIP-110. He argues that participants who want stricter rules are free to operate their own fork, but should not expect the wider Bitcoin economy to recognize it as the primary network.

Back’s position reflects an important distinction in Bitcoin governance. Anyone can release software with new rules. The difficult part is persuading miners, exchanges, wallets, merchants and holders to accept the resulting chain as Bitcoin.

Security engineer Jameson Lopp has also criticized BIP-110 as technically risky and philosophically inconsistent with censorship resistance. Lopp argues that Bitcoin’s value comes partly from users being able to predict that valid transactions will remain valid without receiving social approval from influential groups.

Restrictions designed to target inscriptions could also affect sophisticated scripts that were never intended for data storage. Unknown applications are particularly difficult to protect because developers cannot test compatibility with software and transaction structures they do not know exist.

David Bailey, the chairman and chief executive of Bitcoin treasury company Nakamoto, went further by describing the campaign as a “hostile takeover attempt.” He portrayed its lack of miner support as evidence that Bitcoin’s decentralized governance successfully resisted pressure from a motivated minority.

The language has become inflammatory on both sides. Yet beneath the rhetoric is a legitimate disagreement over whether Bitcoin should defend neutrality by refusing to classify transaction content—or defend decentralization by preventing users from forcing unwanted data onto node operators.

Miner Support Has Barely Materialized

Despite months of campaigning, BIP-110 has failed to attract meaningful mining support.

Ocean has signaled for the proposal, but the largest mining pools have not followed. Across monitored signaling periods, support has remained below approximately 1%, far from the proposal’s 55% threshold.

Node adoption has also remained limited and is concentrated largely among users of Bitcoin Knots, an alternative node implementation that offers more restrictive filtering controls than Bitcoin Core.

These figures do not constitute a perfectly democratic vote. One visible node does not necessarily represent one person, one company or one unit of economic influence. Nodes can be hidden, duplicated or temporarily connected. Miner signaling is also usually controlled by pool operators rather than every individual machine contributing computing power.

Nevertheless, support this low sends a clear coordination signal. The major infrastructure participants are not preparing to enforce BIP-110.

Calling the proposal officially defeated would still be premature. Its activation mechanism contains a mandatory-signaling phase intended to force a decision before the deadline. Nodes running the BIP-110 software would begin rejecting blocks that fail to signal during that period.

With broad support, such a mechanism could pressure miners to coordinate around the new rules.

Without broad support, the same mechanism could isolate BIP-110 nodes on a minority chain.

What Bitcoin Miners Actually Do

The debate has also exposed confusion about the role of miners in Bitcoin governance.

Miners collect transactions, arrange them into candidate blocks and perform the proof-of-work calculations required to add those blocks to the blockchain. They usually prioritize transactions offering the most attractive fees, although pools can apply additional filtering policies.

Mining pools can also place signals inside block-version fields to indicate readiness for proposed rule changes. BIP-110 uses one of these version bits.

However, miners do not possess unilateral power to rewrite Bitcoin’s rules.

Full nodes independently validate every block. A miner that creates a block violating the rules enforced by the wider network will see that block rejected, regardless of how much electricity was used to produce it.

At the same time, full nodes cannot force miners to create blocks under new rules merely by installing different software. When only a small minority enforces stricter conditions, those nodes may reject the dominant chain while the rest of the economy continues without them.

This creates a balance among miners, developers, node operators and economic users.

Developers propose and publish code. Nodes choose which code to run. Miners decide which valid transactions to include and which chain to extend. Exchanges, businesses and holders determine which chain has economic value.

No group controls the system independently. Successful changes usually require coordination across several of them.

Miner signaling is therefore not a binding election. It is a public indication of readiness and an important measure of whether a rule change can activate without operational chaos.

The 55% Threshold Is the Most Dangerous Number in the Debate

BIP-110 requires 1,109 signaling blocks within a 2,016-block adjustment period, equivalent to approximately 55%.

Supporters justify the lower-than-usual threshold by noting that the proposal is temporary and addresses what they regard as an urgent threat. Waiting for near-universal agreement, they argue, would allow arbitrary-data ecosystems to become more deeply embedded and politically difficult to remove.

Opponents see the threshold as evidence that the proposal lacks the caution required for consensus changes.

A rule supported by 55% of recent blocks could still leave a large minority of miners producing blocks rejected by upgraded nodes. Exchanges could suspend deposits, wallets might follow different chains and users could face uncertainty over which transactions were final.

Bitcoin has survived previous protocol conflicts, including the block-size war and the activation of Segregated Witness. The lesson many participants drew from those episodes was not that contentious forks are harmless, but that changes require strong coordination among users, miners and businesses.

BIP-110 has not demonstrated anything close to that alignment.

What Happens Next

The proposal’s mandatory-signaling period is scheduled around blocks 961,632 through 963,647. It is designed to produce lock-in by block 963,648, with enforcement of the new transaction rules expected around block 965,664.

Under the BIP-110 schedule, the restrictions would then remain active for 52,416 blocks, approximately one year.

The code can reach those heights regardless of political support. The crucial question is which chain the economy will follow.

With miner signaling still negligible, the most likely outcome is that the dominant Bitcoin chain continues under existing consensus rules. Nodes enforcing BIP-110 could then separate from it if they reject non-signaling blocks or blocks containing transactions prohibited by the proposal.

That would not automatically create a valuable competitor. A minority chain needs mining power, liquidity, exchange support, wallet infrastructure and users willing to assign value to it.

Without those elements, it becomes an ideological fork with little economic activity.

A dramatic shift in support remains technically possible, but the window for such a reversal is narrowing. Major mining pools would need to change position rapidly, and economic participants would need to demonstrate that the signaling represented more than temporary coordination.

Bitcoin’s Governance Is the Real Story

BIP-110 is often described as a battle over spam, Ordinals or images stored on the blockchain. Those are only the visible triggers.

The real dispute concerns who gets to define legitimate Bitcoin use.

Supporters believe Bitcoin must actively defend its monetary purpose or risk becoming an expensive permanent storage system for applications that could operate elsewhere. Opponents believe Bitcoin protects its monetary value by refusing to let developers or social majorities classify valid transactions according to subjective intent.

Both sides claim to be defending decentralization. They disagree on what decentralization requires.

For BIP-110, the immediate numbers are unforgiving. Miner support remains negligible, node adoption is limited and several influential figures have publicly rejected the proposal. Unless that changes rapidly, the attempt to restrict arbitrary data through consensus is likely to end in failure or a small minority fork.

But the pressure that produced BIP-110 remains. Bitcoin will continue attracting inscriptions, tokens, experimental protocols and uses its earliest supporters never anticipated.

The network may reject this particular solution. It has not resolved the underlying question.

Bitcoin still has to decide whether neutrality means accepting every valid fee-paying transaction—or whether preserving neutral money sometimes requires saying no to everything else.

Allbridge Core has become the latest cross-chain protocol to discover how quickly a liquidity imbalance can turn into a seven-figure loss. An attacker exploited the bridge’s Solana deployment for an estimated $1.65 million, moved the stolen assets from Solana to Ethereum and began routing the funds through mechanisms designed to make the trail more difficult to follow.

Allbridge paused its Core protocol while investigating the incident and urged liquidity providers with funds in the affected pools to withdraw. The company has not yet released a complete technical post-mortem, leaving security researchers and onchain analysts to reconstruct the attack from the transactions visible on Solana and Ethereum.

The early evidence points to a flash-loan-assisted manipulation of a stablecoin liquidity pool rather than a compromise of private keys or the bridge’s validator infrastructure. That distinction explains the mechanics of the attack, but it does little to reduce the consequences for liquidity providers whose capital was exposed to the distorted pool.

A Flash Loan Turned Liquidity Into a Weapon

According to initial analysis from Onchain Lens, the attacker borrowed approximately $1.12 million in USDC through a flash loan from Kamino, a Solana-based liquidity protocol.

A flash loan allows a user to borrow substantial capital without posting traditional collateral, provided that the loan is repaid within the same blockchain transaction. The feature is useful for legitimate arbitrage, refinancing and liquidity management. It also gives attackers access to enough temporary capital to manipulate markets that would otherwise be too expensive to influence.

In this case, the borrowed USDC was reportedly used to execute rapid swaps between USDC and USDT inside an Allbridge Core liquidity pool. Both assets are designed to trade close to one US dollar, but their exchange rate inside an automated pool depends on the pool’s reserves and pricing formula.

By pushing a large amount of capital through the pool in a carefully structured sequence, the attacker appears to have distorted the relationship between the two stablecoins. Once the pool was sufficiently imbalanced, assets could be withdrawn at an exchange rate that no longer reflected their real market value.

The attacker then repaid the flash loan while retaining the extracted value. Blockchain-security firms PeckShield and CertiK estimated the total loss at roughly $1.65 million.

The entire operation demonstrates why flash-loan attacks can be so effective. The attacker does not need to own the capital used to manipulate the pool. They only need to identify a pricing mechanism that can be pushed into an unsafe state and complete the full sequence before the transaction ends.

If any step fails, the transaction can revert and the borrowed funds return to the lender. If the exploit succeeds, the attacker repays the loan and keeps the difference.

Stolen Assets Crossed From Solana to Ethereum

After extracting the funds, the attacker reportedly bridged the stolen assets from Solana to Ethereum and converted them into ETH.

The move was strategically significant. Ethereum provides access to deeper liquidity, a larger collection of decentralized exchanges and a wider range of privacy tools. Moving the assets also complicates recovery efforts because investigators must follow the funds across multiple networks, bridge transactions, token conversions and potentially numerous wallet addresses.

Onchain analysts reported that some of the funds were subsequently directed toward privacy-oriented pools. These protocols can combine deposits from multiple users and make it more difficult to connect the original source of an asset with its eventual destination.

Blockchain transactions remain public, but public does not always mean easily attributable. Investigators can watch funds enter a privacy system without necessarily knowing where the same value later exits.

Speed is therefore critical after an exploit. Security teams may try to contact exchanges, stablecoin issuers, bridge operators and other infrastructure providers before the attacker can disperse the assets. Once the funds have been divided, swapped and routed through privacy services, the chances of a straightforward recovery decrease substantially.

The transfer to Ethereum does not mean the attacker has escaped detection. It does, however, suggest an effort to move beyond the environment where the exploit occurred and gain access to a broader set of laundering options.

Allbridge Pauses Core and Warns Liquidity Providers

Allbridge said it paused the protocol as a precaution while investigating the security incident. The team also told liquidity providers with funds in the affected pools to withdraw immediately.

That warning reflects a second layer of risk created by the exploit. Even after the attacker completes the main extraction, the damaged pool can remain severely imbalanced. Liquidity-provider positions may therefore no longer represent the asset composition or value that depositors originally expected.

Allbridge acknowledged that the imbalance temporarily created a profitable arbitrage opportunity. Traders who noticed the distorted pricing could exchange assets at favorable rates, potentially extracting additional value from the affected pool even without participating in the original exploit.

This creates a complicated recovery problem. Some transactions executed after the attack may have been ordinary arbitrage rather than malicious activity. From the pool’s perspective, however, both can deepen the losses experienced by liquidity providers.

Allbridge asked traders who benefited from the temporary arbitrage window to consider returning the proceeds, saying that recovered funds would be used to compensate affected LPs. The company stated that its objective is to return all affected funds to users.

Whether that is achievable will depend on how much capital can be recovered, the final size of the losses and the technical details revealed by the investigation.

For LPs, the immediate priority is not chasing yield or attempting to trade around the imbalance. It is following the protocol’s official instructions, withdrawing from affected pools where possible and avoiding further deposits until Allbridge has explained the vulnerability and completed its remediation process.

Why Stablecoin Pools Are Not Automatically Stable

The exploit also exposes a persistent misconception surrounding stablecoin liquidity.

USDC and USDT are both intended to maintain a value close to one dollar. That does not mean every exchange between them is protected from manipulation. A decentralized pool calculates prices according to its reserves and smart-contract logic, not according to a universal guarantee that one stablecoin must always equal another.

Stablecoin-focused automated market makers are typically designed to offer low-slippage trades when assets remain close to parity. The efficiency comes from specialized pricing curves that assume the tokens should trade within a narrow range.

That assumption can become dangerous if an attacker can artificially shift the pool’s reserves or exploit a weakness in the way deposits, withdrawals and swaps are calculated. A formula optimized for efficient stablecoin trading may behave unpredictably when subjected to a transaction sequence that its designers did not adequately anticipate.

The key question is not simply whether USDC and USDT remained close to one dollar on external markets. It is whether Allbridge Core’s internal accounting allowed the attacker to create and monetize a temporary discrepancy inside the protocol.

A full technical assessment will need to establish which checks failed, whether the vulnerability was specific to the Solana implementation and whether equivalent attack paths exist in any other Allbridge pools.

A Familiar Problem for Allbridge

This is not the first time Allbridge has faced a flash-loan-related security incident.

In April 2023, an attacker exploited an Allbridge liquidity pool on BNB Chain and drained approximately $573,000. That incident also involved manipulation of a stablecoin pool’s pricing mechanism. Part of the stolen money was later returned after the project offered the attacker an opportunity to act as a white-hat participant.

The similarity does not necessarily mean the same vulnerability survived unchanged for more than three years. The current exploit affected a different blockchain deployment and may involve separate code, assumptions or implementation details.

It does, however, place additional pressure on Allbridge to explain how the latest attack bypassed its defenses. Users will want to know what was changed after the 2023 incident, whether the new exploit shared any underlying design characteristics with the earlier attack and how the protocol plans to prevent a third occurrence.

Security reviews cannot focus only on previously identified lines of vulnerable code. They must also examine the broader economic conditions that made the exploit possible.

A contract can function exactly as written and still produce a catastrophic result if its pricing model, liquidity assumptions or transaction limits allow an attacker to manipulate the system profitably.

Cross-Chain Bridges Remain High-Value Targets

Cross-chain bridges occupy one of the most demanding positions in decentralized finance. They must coordinate assets and messages between networks that operate under different technical rules, while maintaining enough liquidity to make transfers practical.

That concentration of capital makes bridges attractive targets. Their complexity creates numerous places where security can fail, including smart contracts, liquidity pools, price calculations, message validation, privileged accounts and external dependencies.

The Allbridge incident appears to have targeted a liquidity mechanism rather than the bridge’s cross-chain verification system. Nevertheless, the attack reinforces the wider bridge-security problem: an attacker only needs to compromise one economically important component to place user funds at risk.

Audits remain necessary, but they cannot guarantee that every possible transaction sequence has been anticipated. Protocols also need active monitoring capable of detecting unusual pool imbalances, rapid high-value swaps and withdrawals that diverge sharply from normal activity.

Circuit breakers can help by automatically pausing activity when reserves move beyond predefined thresholds. Flash-loan-resistant pricing, withdrawal limits and time-weighted calculations can also reduce the ability of an attacker to create and exploit a temporary price distortion within a single transaction.

These defenses introduce trade-offs. Limits can make markets less efficient, pauses can interfere with legitimate users and slower pricing mechanisms may create other forms of risk. The alternative, however, is a system optimized for speed during normal conditions but unable to defend itself when capital arrives specifically to break its assumptions.

The Investigation Will Determine the Real Damage

The current $1.65 million figure is an estimate from blockchain-security analysts rather than a final loss calculation from Allbridge. The amount could change as investigators distinguish the original extraction from subsequent arbitrage, trace remaining funds and examine the exact condition of affected LP positions.

Allbridge’s next updates will need to address more than the status of the stolen assets. Liquidity providers will expect a clear accounting of losses, a compensation framework and an explanation of which pools were affected.

The protocol will also need to describe how it intends to restore operations safely. Reopening without a detailed diagnosis would leave users dependent on assurances rather than evidence.

A credible recovery process should include a technical post-mortem, independent review of the fix and a clear explanation of the safeguards added to detect similar manipulation. The company’s decision to pause the protocol limits immediate exposure, but the long-term test will be whether the incident leads to a stronger design.

For now, the message to affected liquidity providers is direct: withdraw from the impacted pools and wait for verified information from Allbridge before returning capital.

The attacker has already moved quickly. Allbridge’s challenge is to ensure its investigation is just as decisive—and considerably more transparent.