TL;DR
On August 18, 2026, at around 17:32 UTC, an attacker drained roughly $1.7 million in Bitcoin and other assets from Maya Protocol, a cross-chain DEX that runs its own MAYAChain, a THORChain fork built on the Cosmos SDK. No single bug did it. A single transaction carrying 23 messages tricked the network into thinking an outbound transfer had gone missing, fired a theft-compensation routine, and let an uncapped subsidy credit a thin Arbitrum Chainlink (ARB.LINK) pool with 49.45 million CACAO the reserve never actually held. The attacker then added a token of liquidity, ended up owning 99.93% of the inflated pool, and withdrew 48.87 million CACAO from the Asgard vault. On-chain, 20.83 BTC worth about $1.34 million landed in one address. The wider damage was larger and mostly indirect: CACAO fell nearly 89% and pool value dropped about $10.9 million, most of it price collapse and arbitrage, not theft. Six medium-severity flaws that each survived review composed into one critical the moment they shared state.
What Actually Happened to Maya Protocol?
Maya Protocol halted MAYAChain after an attacker chained six software bugs to fake a balance that was never funded. Founder Aaluxx, posting as @AaluxxMyth, put it flatly: "No way to sugar coat this. We have likely been exploited by 20 BTC ($1.4M) and other assets ($300k)." The team stopped all trading to contain the outflow and said it would fix the vulnerability before resuming swaps.
MAYAChain is a smaller cross-chain network that lets users swap native assets like Bitcoin and Ether without a centralized exchange, using CACAO as the common asset across every pool. It is a fork of THORChain, built on the Cosmos SDK with Tendermint consensus and threshold signatures, and it had run since its 2023 launch without a documented loss-of-funds event until this attack. The code the attacker abused was old. According to the team's own account, the bugs sat undiscovered for three to four years across multiple security reviews. Six flaws a reviewer could sign off on one at a time added up to a critical once a single transaction ran them together, which is the class of failure a module-by-module audit is built to miss.
How Did the Six-Bug Chain Work?
The whole attack turns on one primitive. When MAYAChain believes protocol funds were lost in an outbound transfer, it runs a theft-protection routine that compensates the affected liquidity pool. Think of it as insurance the chain pays itself: a pool recorded as short-changed by a missing send gets credited back so its liquidity providers are made whole. That credit is supposed to be funded from the network reserve and bounded by what the reserve can actually pay. Here it was neither.
The attacker packed 23 messages into one MsgDeposit transaction so that several parts of the accounting system moved inside a single atomic block, before any human or automated check could react between steps. The team's postmortem describes the shape precisely: the transaction was used "to trigger a false 'theft' detection, inflate a low-liquidity pool's CACAO balance via an uncapped slash subsidy, then immediately LP'd into and withdrew from the inflated pool to extract the value." The credit, the liquidity add, and the Asgard withdrawal all rode inside that one transaction.
The crafted messages overwrote the records that track outbound transfers, so the chain decided a legitimate outbound send had gone missing. That false alarm fired the theft-compensation path. The compensation math had no upper bound, so it credited the thin ARB.LINK pool with 49.45 million CACAO. The payment that was meant to fund that credit came from the reserve, and the reserve held only about 168,000 CACAO. It could not cover a payout nearly three hundred times its own balance. The funding transfer failed.
One more bug turned the accounting glitch into a heist. The failed payment did not roll back the credit. The inflated 49.45 million balance had already been written to the pool's state, and MAYAChain kept operating as though the tokens were really there. A transfer that could not be funded left a permanent, phantom balance behind it.
This is an atomicity failure, and it has a specific shape on a Cosmos SDK chain like MAYAChain. The safe pattern is to stage a handler's state writes in a branched, cached context and commit them only if the whole operation, funding transfer included, succeeds; if any step fails, the branch is discarded and nothing persists. When a credit is written to the live store and the funding failure is swallowed instead of returned as an error that aborts the message, the write stays. The public postmortem does not spell out which safeguard was absent, so treat the exact code-level cause as inferred; the observable result is a committed balance with no transfer behind it.
The choice of the thin ARB.LINK pool looks deliberate: the less real liquidity a pool holds, the less an attacker must deposit to dominate it once it is falsely credited, so the network's smallest pool was its cheapest to capture.
From there the exit was mechanical. The attacker added a negligible amount of liquidity to the distorted pool. Because the pool's on-book value was almost entirely phantom CACAO, that tiny deposit bought 99.93% ownership of it. They withdrew 48.87 million CACAO from Asgard, the module that holds Maya's real protocol assets, and swapped it for the Bitcoin, Ether, and stablecoins sitting in the other pools. That 48.87 million is a little under the 49.45 million credited. Ownership alone does not account for the roughly 580,000-token gap: 99.93% of the credit would be about 49.42 million, so the missing tokens are more than the sliver the attacker did not own. The public reconstruction does not itemize the difference, and we leave it unexplained rather than reverse-engineer a reason.
The Attack, Step by Step
| Step | Action | Effect |
|---|---|---|
| 1 | Submit one MsgDeposit carrying 23 messages | Batches every accounting change into one atomic block |
| 2 | Overwrite outbound-transfer records | Chain marks a legitimate transfer as "missing" |
| 3 | False theft detection fires | Theft-compensation routine activates |
| 4 | Uncapped slash subsidy runs | ARB.LINK pool credited +49.45M CACAO |
| 5 | Reserve holds only ~168,000 CACAO | Funding transfer for the credit fails |
| 6 | Failed transfer does not roll back state | Phantom 49.45M balance persists in the pool |
| 7 | Add negligible liquidity to the pool | Attacker now owns 99.93% of it |
| 8 | Withdraw 48.87M CACAO from Asgard | Phantom balance converted to real protocol assets |
| 9 | Swap CACAO for BTC/ETH/stables across pools | 20.83 BTC routed to the attacker address |
| 10 | Network halt triggered | Outflow contained, but the drain partly beat it |
The order of the steps matters less than the interplay between the modules that should have stopped each other, so the sequence below shows who talked to whom.
Reconciling the Theft: $1.7M Taken, $11M in Pool Damage
The headline number moved around, and the gap between the versions is the story. The $10.9 million "pool value" figure and the $1.7 million "stolen" figure measure different things.
The attacker personally extracted about $1.65 million, including tokens still held on-chain. Of that, roughly $1.36 million left MAYAChain onto external blockchains, and about $291,000 in positions stayed on Maya. The most concrete piece is the Bitcoin, where PeckShield traced 20.83 BTC to a single address, bc1q0hsgwunccczelq05ucpmfz268eyy5jr2y5l646, funded in ten transactions on August 18 at 17:32 UTC. That address is verifiable directly: on-chain it holds about 20.827 BTC, none of it spent as of August 20, 2026. That is the hard floor on the loss, and it is the number to trust because it does not depend on anyone's price assumptions.
The $10.9 million is a different measurement entirely. MAYAChain's own reconstruction estimates pool value fell by about that much during the event, but roughly $6.4 million of the drop was CACAO simply becoming less valuable as the attacker sold into it, and about $2.9 million came from arbitrage traders buying the suddenly cheap token and swapping it for real assets in Maya's pools. CACAO traded around $0.115 before the exploit, fell as low as $0.013 (a drop of about 88.7%), and recovered toward $0.03. The attacker took roughly $1.65 million; the market and the arbitrageurs did the rest.
That distinction matters for anyone modeling the blast radius of a pool-inflation bug. The direct theft is bounded by what the attacker can carry off before the halt; the indirect damage, the part that hurts ordinary liquidity providers, is bounded by how far the token can fall and how much arbitrage the dislocation invites. It is usually the bigger number, and none of it is recoverable the way the traced BTC still might be.
Three things are not in the public record as of writing. There is no published trace of the non-BTC portion, the roughly $291,000 that stayed on-chain, past that one named Bitcoin address. There is no account of how a chain of bugs dormant for years was found and tested before the live transaction. And no source gives the minutes between the exploit and the network halt, the figure that would settle how much room a monitor actually had. We flag all three rather than guess.
Why This Matters: The Audit Case for Cross-Module Invariants
An audit certifies the code you showed it, in the scope you showed it, on the day you showed it. It grades functions and modules. It is very good at the questions "is this mint bounded?" and "does this transfer roll back on failure?" when those questions are asked inside one module. Maya was audited over years, including Cosmos security reviews by Halborn. The bugs still shipped, and the founder's own read afterward was that the team needs to "get even more adversarial and look for extremely simple code primitives."
Consider what each of the six flaws actually was. A theft detector that could be tripped by overwriting outbound records. A compensation routine with no cap on the subsidy it could grant. A reserve payment that could fail. A state write that was not reverted when its funding failed. A pool-share calculation that treated a phantom balance as real. A withdrawal path from Asgard that trusted the pool's on-book number. Read in isolation, most of these look like defensible design or, at worst, a medium-severity note in an audit report. The uncapped subsidy is the one primitive that a line-level review should have flagged, and the non-atomic state write is the second. Those two are ordinary code bugs, and an audit's job is to catch them.
The other four live between the modules rather than inside any one of them. They are assumptions about how modules relate. The theft detector assumes outbound records are trustworthy. The withdrawal path assumes the pool balance reflects funded value. Each is reasonable until you place it next to the module that violates it. That is the invariant that lives between components, and no module-scoped audit is looking for it, because it is not in any one module to find.
We have seen this shape before under different names. Reserve manipulation is the class where an attacker distorts a protocol's internal accounting of what it holds and then withdraws against the fiction. Flash-loan pool manipulation is the class where a pool's own balance math is skewed inside one transaction so a withdrawal pays out far more than it should. Maya is a cousin of both, produced not by one clever trick but by six ordinary ones sharing a transaction. Forking THORChain gave Maya a hardened, battle-tested codebase, which is genuinely a security advantage. It also meant inheriting a set of cross-module assumptions that were never re-proven for Maya's own reserve sizes and pool depths. Those unstated invariants travelled with the forked code, and no one re-checked them against Maya's own numbers.
Operator Takeaways
- Test invariants across modules, not just within them. The bugs that mattered here were relationships, not lines: "the withdrawal path trusts a balance the compensation path can forge." Write the cross-module invariants down as explicit properties ("no pool balance exceeds funded backing," "no credit persists without a completed funding transfer") and fuzz them against the whole state machine, not one handler at a time.
- Cap every automatic subsidy, mint, and compensation path. An uncapped payout routine is a loaded gun aimed at your reserve. Any code that can increase a balance without a corresponding user deposit needs a hard ceiling tied to what actually backs it, checked at execution, not at proposal time.
- Make failed transfers roll back the state they touched. The heist existed because a credit survived a payment that failed to fund it. State changes and the transfers that fund them must be atomic: the balance should move only when the money behind it does. Assert solvency after the whole message batch, not per message.
- Monitor pool ownership and reserve-versus-credit mismatches, and be honest about the window. Because the whole mint-to-withdrawal sequence executed in one atomic transaction, no monitor could have interrupted it mid-block. The window that mattered came after, when the attacker still had to swap the CACAO for Bitcoin and move it off-chain across further transactions. A single address holding 99.93% of a pool, or a pool credited 49.45 million against a reserve of 168,000, are loud, machine-detectable anomalies the moment the block commits. Catching them there is what buys the minutes to freeze routes and warn exchanges before the funds bridge out.
- Re-prove inherited assumptions when you fork. A fork inherits the parent's invariants along with its code, and those invariants were tuned to the parent's reserve sizes, pool depths, and parameters. Treat every assumption in forked code as unverified for your own numbers until you have tested it against them.
The honest split on prevention: the uncapped subsidy and the non-atomic state write are code bugs a deep human audit should catch, and that is where a review like our Full Audits earns its place. The composition across six modules is the part audits routinely miss, and the pool-ownership and reserve-mismatch signals are observable at runtime. Our Tripwire monitoring layer is built for that second category, the anomaly that no single function reveals but that shows up once you watch the whole system's balances against what backs them.
Frequently Asked Questions
What happened to Maya Protocol in August 2026? On August 18, 2026, an attacker chained six bugs in MAYAChain's accounting to inflate an ARB.LINK pool with 49.45 million CACAO that was never funded, took 99.93% ownership of it, and withdrew 48.87 million CACAO from the Asgard vault. About 20.83 BTC ($1.34 million) and other assets left the protocol, for roughly $1.65 million in direct theft. Maya halted the network to contain it.
Was $11 million stolen? No. Pool value fell about $10.9 million during the event, but most of that was CACAO's roughly 89% price collapse (about $6.4 million) and arbitrage against the price dislocation (about $2.9 million). The direct theft is smaller and the two published figures agree closely: the team's initial estimate was about $1.7 million (20 BTC near $1.4 million plus roughly $300,000 in other assets), and the later reconstruction put the attacker's personal take at about $1.65 million, of which roughly $1.36 million reached external chains. Read the direct theft as roughly $1.65 to $1.7 million. The $10.9 million is a separate measurement: total pool damage including market effects.
Would an audit have caught this? Partly. Two of the six flaws, the uncapped compensation subsidy and the non-atomic state write, are code-level bugs a thorough audit should flag. The other four were cross-module assumptions, reasonable in isolation and dangerous only in combination. Maya had been audited over several years, including by Halborn, and the bugs still shipped. That is the argument for invariant testing across module boundaries, not function-by-function review alone.
Is Maya Protocol a THORChain fork, and is THORChain affected? Maya is a fork of THORChain built on the Cosmos SDK with Tendermint consensus and threshold signatures. The specific bug chain reported here concerns Maya's own theft-compensation and pool-accounting code and its own reserve and pool sizes. There is no public reporting that THORChain shares this exact composition. The same question applies to other THORChain-derived chains: whether any run the same theft-compensation and uncapped-subsidy code is unanswered in the public record, and it is the follow-up worth running. A fork carries over the parent's design assumptions, so the general lesson about re-proving invariants applies, but the incident as described is Maya's alone.
Can users recover their funds? Uncertain as of publication. Maya said it hopes the attacker returns the funds in exchange for a bug bounty. Failing that, the team said it would replace the roughly 20 BTC and return it to the affected pool by other means, including drawing on its Aztec Chain investments. Repairing the software does not by itself restore the pools, because much of the CACAO created by the exploit was already swapped into other markets and is now mixed with tokens belonging to ordinary liquidity providers.
Sources / References
- CoinDesk: Maya Protocol exploit drains bitcoin and other assets as pool value drops $11 million
- Decrypt: Six-Bug Exploit Halts Maya Protocol After $1.4 Million in Bitcoin Stolen
- Cointelegraph: Maya Protocol Hit by $1.7M Exploit, CACAO Falls 89%
- Bitcoin.com News: PeckShield traces 20 BTC to attacker wallet
- mempool.space: attacker Bitcoin address (on-chain balance)
- Crypto Times: Maya Protocol hit by $1.7M exploit in first major breach since 2023
- Maya Protocol documentation: Audits
- SigIntZero: Allbridge Core $1.65M flash-loan pool manipulation
- SigIntZero: Reserve manipulation isn't dead
Disclosure: SigIntZero is a Web3 security firm offering smart-contract audits, runtime monitoring (Tripwire), and incident response. This analysis is based on public reporting and on-chain data available at the time of writing; figures are the protocol's and third-party estimates and may be revised.



