Maya Protocol Exploit Explained: Why CACAO and BTC Pools Lost Far More Than the Attacker Took

Maya Protocol halted cross-chain trading after an exploit that reportedly extracted roughly $1.7 million in assets, triggered severe disruption across its liquidity pools and sent CACAO sharply lower. But the most important number in this incident may not be the amount the attacker reportedly took. A separate estimate put the decline in Maya’s pool value at roughly $11 million, creating an obvious question: how can a $1.7 million exploit produce economic damage many times larger?

The answer lies in how Maya Protocol works. Direct attacker proceeds, native assets leaving liquidity pools, the mark-to-market decline in CACAO, arbitrage and liquidity-provider losses are different measurements. Combining them into a single “hack loss” figure gives readers the wrong picture of what actually happened.

That distinction is especially important on Maya because CACAO is deeply embedded in the protocol’s cross-chain liquidity model. When CACAO reprices violently, its decline can affect the dollar value of multiple pools at once—even though those lost dollars never entered an attacker’s wallet.

What happened to Maya Protocol?

Maya Protocol operates a native cross-chain automated market maker through MAYAChain. Instead of simply minting a wrapped representation of Bitcoin or another asset on a destination chain, Maya coordinates native assets held in network-controlled vaults and uses its internal liquidity pools to execute cross-chain swaps.

A simplified BTC-to-ETH trade illustrates the model. A user can send native BTC to a Maya-controlled Bitcoin vault. MAYAChain observes the transaction, the swap moves economically through BTC/CACAO and CACAO/ETH liquidity, and Maya’s Ethereum-side vault can then sign the outbound ETH transaction.

This architecture matters because describing the incident as simply a “bridge hack” can be misleading. Maya is not a conventional lock-and-mint bridge where native BTC is locked and a wrapped BTC token is minted elsewhere.

For a wider explanation of the different models, CryptoLinks has a detailed guide to cross-chain compatibility, native swaps, bridges and blockchain interoperability.

Native-asset architecture removes some wrapped-token risks, but it does not eliminate state-machine errors, liquidity-accounting failures, vault problems, chain-observation errors or economic exploits.

Did the entire Maya blockchain stop?

No evidence reviewed for this report establishes that MAYAChain itself suffered a consensus halt.

This is an important terminology issue.

Maya has several emergency controls. It can stop signing on a specific chain, pause liquidity-provider activity, halt trading for one connected chain or halt trading across the network.

According to Maya’s own network-halt documentation, setting HALTTRADING stops trading across connected chains while the MAYAChain blockchain can continue producing blocks and processing native CACAO transactions.

That is fundamentally different from the blockchain itself going offline.

So the accurate description of the incident is that Maya halted trading following the exploit. We should only say “MAYAChain stopped producing blocks” if block data demonstrates an actual consensus halt.

How much did the Maya Protocol attacker actually take?

Breaking reports have estimated direct attacker proceeds at approximately $1.7 million.

That number should be understood as an estimate of assets that reportedly ended up under attacker control—not as a measure of every dollar of economic damage suffered by Maya liquidity providers or CACAO holders.

The distinction becomes critical because another widely cited figure placed the decline in Maya’s liquidity-pool value at roughly $11 million.

Those numbers are measuring different things.

I would separate the incident into four layers:

1. Assets actually extracted by the attacker.
2. Native external assets removed from or redistributed across Maya pools.
3. The wider decline in pool value caused by CACAO repricing, arbitrage and changing liquidity.
4. The decline in CACAO’s external market value.

The last three categories do not automatically become attacker profit.

Why could $1.7 million in theft produce an $11 million pool-value decline?

This is the central accounting question in the Maya Protocol exploit.

Imagine a simplified liquidity pool containing $5 million of BTC and $5 million worth of CACAO immediately before an exploit.

If $1 million of BTC disappears, the pool suffers a direct $1 million native-asset loss.

But now imagine CACAO falls sharply in outside markets. The quantity of CACAO sitting in the pool may be unchanged, yet its dollar value could fall by several million dollars.

The quoted USD value of the entire pool therefore declines much more than the amount transferred to the attacker.

Then there is arbitrage.

Automated market makers depend on traders to bring internal pool prices back toward outside market prices. If an exploit knocks a BTC/CACAO or ETH/CACAO pool badly out of balance, arbitrageurs can trade against that imbalance.

Those trades can change the pool’s asset composition and crystallize additional economic damage for liquidity providers.

There may also be LP withdrawals, synth-accounting effects and other state changes occurring during the same period.

The result is:

Direct attacker proceeds can be relatively modest while total liquidity-pool value falls by a much larger amount.

That does not mean the wider pool damage is imaginary. It means we should not call all of it “money stolen by the hacker.”

CACAO’s crash is a major part of the story

CACAO is not merely a token floating beside Maya’s protocol.

It acts as the settlement side of Maya liquidity pools and also plays a role in network fees, incentives and node economic security.

That makes CACAO unusually important during a security incident.

Every major external asset paired against CACAO can be affected when CACAO’s market price collapses. A sharp CACAO repricing reduces the dollar value of the CACAO side of those pools even before we consider any native BTC, ETH, ZEC or other assets that may have left them.

Several forces can accelerate the move:

• existing CACAO holders selling after the security incident;
• arbitrageurs trading internal Maya pool ratios toward external prices;
• liquidity providers reducing exposure where withdrawals are available;
• lower confidence in CACAO’s role in Maya’s economic security;
• thin external liquidity amplifying relatively modest sell orders.

This is one reason percentage price moves during a crisis should be treated carefully. A brief wick in a thin market is not necessarily representative of the price at which a large holder could actually exit.

I would therefore avoid saying that “the attacker destroyed 90% of CACAO” or that CACAO’s entire market-cap decline was part of the hack proceeds.

Market capitalization is a mark-to-market estimate. If a token falls in price, the resulting decline in market cap is not a corresponding pile of dollars deposited into the attacker’s wallet.

What about the reported 20 BTC?

Roughly 20 BTC has been cited in reporting around the Maya Protocol exploit, but that claim should be handled more carefully than simply writing “the hacker stole 20 BTC.”

Bitcoin actually gives investigators a useful advantage here: its public UTXO history makes the underlying transactions traceable.

The important job is classification.

Investigators need to determine which BTC outputs were received by attacker-controlled addresses, whether some were normal protocol refunds or swap outbounds, whether any belonged to independent arbitrage activity, and where the funds subsequently moved.

Until every relevant Bitcoin transaction is reconciled, the safer formulation is that roughly 20 BTC has been reported among the exploit-related asset flows.

Nothing about those BTC movements implies that Bitcoin itself was hacked.

Why this was not a Bitcoin hack

The difference is worth stating explicitly because headlines involving stolen BTC often blur the boundary.

There is no evidence here that Bitcoin’s consensus rules failed, that somebody created unauthorized native BTC, or that Bitcoin’s cryptography was broken.

The incident concerned Maya’s cross-chain protocol logic and the way the system coordinated and accounted for assets that physically exist on other blockchains.

The same principle applies to Ethereum, Zcash and other connected chains unless separate evidence demonstrates a problem with those networks themselves.

CryptoLinks covered the opposite architectural problem in our analysis of the 2026 Hyperbridge exploit and the risks of wrapped cross-chain assets. In that case, understanding the difference between a native asset and its bridged representation was essential.

Maya eliminates that specific wrapped-token model, but native cross-chain swaps introduce a different challenge: several independent systems must agree about balances, state and authorization.

Was Maya’s threshold-signature system compromised?

There is currently no basis to conclude that Maya’s threshold-signature system itself was cryptographically broken or that validator private keys were stolen.

That distinction is crucial.

A threshold-signature vault can correctly sign a transaction that the protocol state tells it is authorized. If the state or accounting leading to that transaction is wrong, the resulting outbound can still be economically harmful without the signing cryptography itself being compromised.

This is why the root-cause investigation needs to answer a more precise question: what allowed an economically invalid outcome to appear sufficiently valid to move through Maya’s normal state and outbound machinery?

The reported multi-bug exploit chain matters more than the bug count

Maya founder Aaluxx’s preliminary explanation described the attacker as combining multiple protocol weaknesses into a single exploit chain.

The phrase “exploit chain” matters.

One bug does not always need to be catastrophic by itself. A state-machine weakness might create an unexpected condition. A second component may fail to reject it. Another accounting path might allow that condition to affect pool balances. A later subsystem may then permit an outbound transaction based on the resulting state.

When composed, weaknesses that appear individually limited can become critical.

The meaningful technical question is therefore not simply whether somebody can count six steps or six transactions.

It is whether the final postmortem identifies six genuinely independent bugs, six necessary exploit conditions, or some combination of code defects, assumptions and economic behavior.

Until that mapping is public, I would treat the multi-bug explanation as preliminary rather than presenting a six-item vulnerability list as settled fact.

Why Maya’s existing security controls are now under scrutiny

Maya already documents a substantial security and emergency-control system.

Its protections include outbound transaction throttling, reactive and proactive solvency checking, unauthorized-transaction detection, security-event monitoring and node-triggered trading halts.

That makes the postmortem particularly interesting.

Outbound throttling is intended to slow large flows enough to give automated checks and node operators more time to react.

Maya’s reactive solvency checking compares the balance the network believes should exist in a vault with the assets actually present on the connected blockchain.

Its proactive check is even more relevant: before signing an outbound, a node can test whether executing that transaction would render the vault insolvent.

If enough nodes report insolvency for a chain, trading on that chain can be halted.

So the important question is not simply, “Did Maya have safeguards?”

It did.

The important question is what information those safeguards were evaluating while the exploit was happening.

If corrupted state made a harmful outbound look legitimate from the protocol’s point of view, a security check could potentially behave exactly as coded while still failing to prevent the economic loss.

That is one of the issues a proper code-level postmortem needs to establish.

What the exploit means for Maya liquidity providers

Liquidity-provider losses cannot be measured simply by looking at the amount the attacker took.

A BTC/CACAO LP can be exposed to several simultaneous effects: native BTC leaving the system, falling CACAO, arbitrage against an imbalanced pool and changes in the amount of each asset represented by that LP’s pool units.

An ETH/CACAO or ZEC/CACAO LP can also lose substantial dollar value through CACAO repricing even if the direct extraction from that particular external-asset side is much smaller.

This is closely related to the broader AMM risks explained in our CryptoLinks guide to liquidity pools, yield farming and impermanent loss.

However, a live security exploit adds another layer. This is no longer just normal price divergence between two assets. LPs may be dealing with damaged pool accounting, abnormal arbitrage and emergency protocol restrictions at the same time.

That is why pool impairment should ultimately be reconstructed using pool depth, LP units, synth liabilities and underlying native-asset balances—not simply one before-and-after USD TVL number.

Could the CACAO decline weaken Maya’s economic security?

Potentially, yes—but it should be measured rather than assumed.

Maya’s node model uses bonded CACAO as part of the economic security protecting assets managed by the network.

If the amount of bonded CACAO remained constant while CACAO’s market price dropped sharply, the dollar value of that bond would decline automatically.

A useful metric is:

Bond coverage = USD value of bonded CACAO ÷ USD value of external assets secured

The ratio should be measured before the exploit, at CACAO’s event low and after the market stabilizes.

A worsening ratio would show that the token-price decline affected more than LP valuations: it also reduced the dollar value of the economic collateral supporting the system.

That does not mean node bonds automatically compensate victims of this exploit. Bond slashing and LP reimbursement are separate questions and should not be conflated without a direct Maya remediation announcement.

A technical fix will not automatically repair the economic damage

This may become the most important distinction over the next stage of the incident.

A team can identify a root cause, patch the vulnerable code and restart trading while liquidity providers are still economically impaired.

That would represent technical recovery without full economic recovery.

We have seen this distinction across DeFi incidents before. Our coverage of the KelpDAO exploit and emergency containment explored the same principle: stopping an attacker or freezing activity is not the same thing as resolving the financial consequences.

For Maya, a responsible restart process should demonstrate that the exploit path is understood, patches have been tested, active nodes are running the appropriate software, vault balances have been reconciled, threshold signing is synchronized and emergency halt controls can be removed safely.

There is also a backlog problem to consider. A cross-chain network may need to reconcile observations and queued transactions before normal operation can resume cleanly.

“Patch complete” and “safe to restart” are therefore not synonymous.

What should Maya users do after the exploit?

The most useful response for ordinary users is operational rather than speculative.

• Check Maya’s authenticated official status before initiating a swap.
• Do not manually send funds to an inbound vault while the relevant halt remains active.
• Save transaction IDs for any transaction caught during the disruption.
• Liquidity providers should record their positions and avoid unofficial withdrawal or compensation tools.
• Do not assume a new “CACAO V2” or migration token is legitimate unless Maya announces it through authenticated official channels.
• Ignore direct messages offering support or reimbursement.
• Never disclose a seed phrase or private key.
• Do not approve an unfamiliar “recovery contract.”

For a wider self-custody checklist, see our guide to wallet safety, passkeys, MPC and crypto recovery.

Crypto exploits reliably attract a second wave of phishing. Fake reimbursement sites and fake migration contracts can appear within hours of a real incident precisely because users are already worried and looking for instructions.

The bigger lesson is about cross-chain state, not simply bridges

The easy takeaway from an incident like this is “cross-chain systems are dangerous.” That is too broad to be useful.

Maya was specifically designed to avoid part of the traditional wrapped-bridge trust model.

But a native cross-chain AMM has its own demanding security problem. It must coordinate MAYAChain’s internal state with Bitcoin confirmation state, EVM transactions, other connected blockchains, vault balances, inbound observations, outbound scheduling, threshold signing, pool accounting, asset-specific gas requirements and external-market arbitrage.

That creates what I would call cross-chain state risk.

Several independent systems need to agree about what happened, what the protocol owns, what users are entitled to receive and which transaction is authorized next.

One faulty assumption can propagate through multiple modules.

This is exactly why exploit-chain testing matters. Security reviews need to test not only individual functions but adversarial transaction sequences and the economic invariants that connect different parts of a protocol.

If you want broader context on the recurring patterns behind major protocol failures, CryptoLinks maintains a guide to the biggest scams and hacks in cryptocurrency history, as well as our broader crypto and DeFi security guide.

My conclusion: the $1.7 million figure is only one part of the Maya Protocol exploit

The biggest mistake in covering the Maya Protocol exploit would be to choose the largest available dollar number and call all of it “stolen.”

The reported approximately $1.7 million figure refers to direct attacker proceeds as currently estimated. The roughly $11 million figure describes a much broader decline in liquidity-pool value. CACAO’s price collapse represents another layer of economic damage again.

Those measurements can move together without being the same thing.

A falling CACAO price can erase millions of dollars from the mark-to-market value of CACAO-heavy pools. Arbitrage can redistribute pool assets after ratios become distorted. Liquidity providers can experience losses beyond whatever assets ended up in attacker-controlled wallets.

None of that means the additional damage is fictional.

It means the accounting matters.

The most useful eventual Maya postmortem will answer four things clearly: exactly what assets reached the attacker, which pools were impaired and by how much, which protocol invariants allowed the attack chain to succeed, and why Maya’s defensive controls did not contain the exploit earlier.

Until those details are fully reconciled, the responsible conclusion is straightforward: Maya suffered a serious cross-chain protocol exploit in which the wider economic damage to CACAO and its liquidity pools appears substantially larger than the amount reportedly extracted by the attacker.

---

Frequently asked questions about the Maya Protocol exploit

What happened to Maya Protocol?

Maya Protocol suffered an exploit that led to an emergency trading halt. The incident affected the economics of its cross-chain liquidity pools and was followed by a sharp decline in CACAO.

How much was stolen from Maya Protocol?

Direct attacker proceeds have been reported at approximately $1.7 million. That estimate should not be confused with the larger decline reported in Maya’s pool value.

Why do reports mention both $1.7 million and $11 million?

The numbers measure different things. Roughly $1.7 million refers to reported attacker proceeds, while approximately $11 million refers to a wider decline in pool value that can include CACAO repricing, arbitrage and other liquidity effects.

Did the attacker steal 20 BTC?

Roughly 20 BTC has been reported among the affected asset flows, but the full UTXO trail must be classified before every bitcoin can be described as attacker proceeds.

Did CACAO crash 90%?

CACAO suffered an extreme repricing, but any precise percentage should be tied to a clearly defined trading venue and UTC time window. Thin liquidity can make short-lived lows look more dramatic than executable market depth would suggest.

Why did CACAO fall after the exploit?

CACAO sits at the center of Maya’s pool economy. Security concerns, market selling, arbitrage, reduced liquidity and reassessment of its role in Maya’s economic security can all amplify price pressure.

Was Bitcoin hacked?

No evidence from this incident indicates that Bitcoin itself was hacked. The failure occurred at the Maya cross-chain protocol layer.

Was Maya’s TSS system broken?

No TSS compromise has been established. A vault transaction can be correctly threshold-signed while still being based on incorrect or exploited protocol state.

Did validators lose their private keys?

There is no established evidence that validator private keys were stolen. That should not be inferred simply because assets left Maya-controlled vaults.

Did the whole MAYAChain blockchain stop?

A trading halt is not the same as a consensus halt. Maya documentation states that a network-wide trading halt can stop swaps while MAYAChain continues producing blocks and processing native CACAO transactions.

Can Maya liquidity providers withdraw?

LP availability depends on the current Maya halt and PAUSELP settings. Users should verify the live official network state before attempting to add or withdraw liquidity.

Will Maya liquidity providers be reimbursed?

No reimbursement should be assumed without a direct, authenticated Maya announcement. Technical recovery, treasury support, socialized losses and LP compensation are separate policy decisions.

When will Maya Protocol fully restart?

A full restart depends on more than writing a patch. The exploit path needs to be closed, nodes updated, vaults and accounting reconciled and relevant emergency controls safely removed before normal cross-chain trading can be considered restored.

Is THORChain affected because Maya shares architectural roots with it?

Not automatically. Shared code ancestry does not prove that another network is exploitable under the same configuration, state and version conditions.

---

Editorial note: This is a developing security incident. Loss estimates, transaction attribution, CACAO pricing, patch status and Maya’s operating state may change as investigators and the protocol publish additional information. CryptoLinks will update material figures when stronger transaction-level or protocol-level evidence becomes available.

This article is informational and does not constitute financial advice.