Maya Protocol's $11M Exploit: How Six Chained Bugs Turned a Ghost Transaction Into a $CACAO Money Printer

On August 19, 2026, an attacker executed a precisely sequenced exploit against MAYAChain, the cross-chain liquidity protocol at the core of Maya Protocol. The attack was not a brute-force intrusion. It was a deliberate, step-by-step traversal of six discrete software defects, each one setting up the next. The result was $1.65M in direct asset theft and $10.9M in total losses when cascading price effects are included.

The attack began around 17:30 UTC on August 18, 2026. The opening move involved manufacturing a false transaction state. The attacker sent a single transaction containing 23 sequentially structured messages, engineered so that the network incorrectly classified an outbound transfer as missing in transit. This is not a trivial deception: it required precise understanding of exactly how MAYAChain's outbound monitoring logic evaluated transaction finality.

That false classification triggered MAYAChain's internal theft-compensation mechanism, a safeguard designed to make liquidity providers whole when funds genuinely disappear during cross-chain transit. The compensation logic responded as designed and credited the low-liquidity Arbitrum Chainlink (ARB.LINK) pool with approximately 49.45 million CACAO tokens. The protocol's Asgard reserve held only around 168,000 CACAO at that moment. The credit was not validated against available reserves before being committed to the pool's state ledger.

The underlying token transfer ultimately failed to settle. But the balance entry had already been written. According to CryptoTimes, another bug meant the new balance had already been saved to the network's records before the failed transfer result was returned. Instead of rolling back the credit when the payment failed, MAYAChain continued operating as though the pool genuinely contained those tokens.

With the pool reflecting a fraudulently inflated $CACAO balance, the attacker deposited a negligible amount of capital into it. Their ownership share was calculated as 99.93% of the pool. They exercised that share immediately, withdrawing 48.87 million CACAO from Asgard and routing it through MAYAChain's swap pools. The attacker extracted approximately 20.83 BTC worth roughly $1.34M, plus approximately $300,000 in additional assets across ARB-based tokens and native CACAO.

Maya Protocol halted MAYAChain once the exploit was identified. The chain suspension prevented further direct drainage but could not reverse the token economics already in motion.

The exploit was not a single vulnerability. It was a composed attack chain spanning six distinct software defects across three subsystems: trade account handling, outbound transaction processing, and liquidity pool calculation. Each defect was individually insufficient to cause material harm. Together, they formed a complete and repeatable exploit path.

Defect 1: Manipulable outbound transaction detection

The base of the chain was a flaw in MAYAChain's observed outbound transaction handler. MAYAChain is a fork of THORChain and shares its core architecture, including the pattern in which network observers watch for outbound transactions and report their status back to the chain state machine. The exploit manipulated the state records for outbound transfers so that a live transaction was classified as missing.

In the MAYANode codebase (hosted at gitlab.com/mayachain/mayanode), the observed txout handler is responsible for updating the status of outgoing transactions as nodes report them. The conceptual flow that was exploited looks like this:

// ObserveTxOut is called when bifrost observers report an outbound tx
func (h ObservedTxOutHandler) handle(ctx cosmos.Context, msg MsgObservedTxOut) error {
    for _, tx := range msg.Txs {
        // Fetch the pending TxOutItem from the store
        voter, err := h.mgr.Keeper().GetObservedTxOutVoter(ctx, tx.Tx.ID)
        if err != nil {
            return err
        }

        voter.Add(tx, msg.Signer)

        // [BUG 1]: The record tracking this outbound tx could be overwritten
        // by a crafted message sequence, causing the voter to appear unsettled
        // even when the transaction had already been broadcast.
        if voter.HasFinalised(h.mgr.GetConstants()) {
            h.mgr.Keeper().SetObservedTxOutVoter(ctx, voter)
            continue
        }

        // If not finalised, trigger missing-tx compensation path
        // [BUG 2]: This path was reached even though the tx had not truly gone missing
        h.slashIfMissingOutboundTx(ctx, voter, tx)
    }
    return nil
}

The exploit forced the code into the compensation path by overwriting the voter record for a real transaction, making it appear unfinalized. The 23-message transaction structure was necessary to sequence these overwrites correctly before the correct observation count was reached.

Defect 2: Write-before-verify in the compensation mechanism

Once the missing-transaction path was triggered, the compensation function calculated a remediation amount and credited it to the affected pool. The critical error was the ordering of operations: the balance was written to state before the function confirmed that the compensating transfer had actually succeeded. The conceptual pattern:

func (vm *VaultMgrV1) compensateForStolenAssets(ctx cosmos.Context, pool Pool, amount cosmos.Uint) error {
    // Calculate compensation amount based on pool state
    compensationAmt := vm.calcCompensation(ctx, pool, amount)

    // [BUG 3]: Balance is credited BEFORE transfer is confirmed
    // If the transfer later fails, the credited balance is NOT rolled back
    pool.BalanceCacao = pool.BalanceCacao.Add(compensationAmt)
    if err := vm.mgr.Keeper().SetPool(ctx, pool); err != nil {
        return err
    }

    // Attempt the actual transfer — but result is not checked
    // against the pool balance write above
    _, err := vm.mgr.txOutStore().TryAddTxOutItem(ctx, vm.mgr, toi, cosmos.ZeroUint())
    if err != nil {
        // [BUG 4]: Error here does not trigger rollback of the pool.BalanceCacao credit
        ctx.Logger().Error("fail to compensate", "error", err)
    }

    return nil // pool balance remains inflated
}

Defects 3 through 6: Amplification and extraction

The four remaining defects allowed the attacker to capitalise on the inflated balance. Pool ownership unit calculations did not validate the depositor's claimed share against independently verified reserve depth. Withdrawal authorisation logic accepted the pool's self-reported balance as ground truth. The TxOut throttler and solvency checks that should have caught the anomalous withdrawal were bypassed because the pool state read by those checks already reflected the fraudulent credit. And swap rate-limiting was insufficient to block the rapid conversion of 48.87M CACAO into Bitcoin and other assets before the anomaly was flagged.

func (h WithdrawLiquidityHandler) handle(ctx cosmos.Context, msg MsgWithdrawLiquidity) error {
    pool, err := h.mgr.Keeper().GetPool(ctx, msg.Asset)

    // [BUG 5]: pool.BalanceCacao is read directly from state
    // State was poisoned by the compensation write in step 2
    // No independent reserve check is performed here
    withdrawAmt := calcWithdrawAmount(pool, msg.WithdrawBasisPoints)

    // withdrawAmt is now 48.87M CACAO — far exceeding actual reserves
    // [BUG 6]: Solvency check uses pool state, not Asgard vault balance
    if !h.mgr.Keeper().VaultSolvencyCheck(ctx, pool.Asset, withdrawAmt) {
        return errInsufficientFunds
    }
    // VaultSolvencyCheck passes because it reads pool.BalanceCacao (poisoned)
    // not the actual Asgard vault holding (~168K CACAO)

    return h.processWithdrawal(ctx, pool, msg.Signer, withdrawAmt)
}

The attack chain had multiple points at which a single additional control would have broken it entirely. Layered defences matter precisely because sophisticated attackers will find and exploit the weakest link in a sequence.

• Confirm before crediting. The compensation mechanism must operate on an escrow-and-release model. Pool balance credits should be staged but not committed until the compensating transfer is confirmed as finally failed through independent verification. A rollback path must exist for every credit write.
• Validate credits against protocol-wide reserve invariants. Any credit that would increase a pool's balance beyond the total available in the corresponding Asgard vault should be hard-rejected. This invariant check is a one-line guard that costs nothing during normal operation and would have made the 49.45M CACAO credit impossible to commit.
• Harden outbound transaction finality detection. The missing-transaction detector should require confirmation from a supermajority of independent observer nodes before triggering compensation. A single message sequence should not be able to manufacture an unfinalized state for a transaction that was broadcast successfully.
• Validate withdrawals against Asgard vault balance, not pool state.Pool state is a derived representation that can be poisoned. Withdrawal authorisation must cross-reference against the independently maintained Asgard vault balance. If these two figures diverge beyond a defined tolerance, the withdrawal should be blocked.
• Apply swap volume rate-limiting as a circuit breaker. A swap of 48.87M CACAO has no precedent in normal protocol operation. Volume-based rate-limiting with a mandatory time-lock for anomalous sizes would have created an intervention window even after the balance was inflated.
• Formally verify all compensation and minting code paths. Any function capable of crediting assets outside the standard issuance flow must be treated as a critical security surface and subjected to formal verification before deployment.