Incident case

MAYAChain 2026 chained accounting exploit

On August 18, 2026, an attacker used a single transaction containing 23 messages to chain multiple MAYAChain accounting and state-handling defects. The sequence triggered a false theft condition and an unfunded slash-subsidy credit in the thin ARB.LINK pool, after which the attacker gained near-total pool ownership and extracted Bitcoin and other assets. Maya halted MAYAChain trading for containment and recovery work.

reviewedcurrent

Incident facts

Incident title
MAYAChain 2026 chained accounting exploit
Bridge
Maya Protocol / MAYAChain
Incident date
2026-08-18
Incident type
Exploit
Major incident
Yes
Affected chains
Bitcoin, Ethereum, Arbitrum, Unknown
Affected assets
BTC, Unknown
Attack category
Unknown
Reported loss
Approximately $1.7 million direct extraction
Amount confidence
Medium
Loss amount basis
Operator Disclosures Corroborated By Independent Reporting
Recovery
Unknown
Reimbursement
Unknown
Restart
Paused
Current outcome
Unknown
Postmortem
Partial
Resolution
Unresolved
Last reviewed
2026-09-09
Last verified
2026-09-09

Amount and valuation

Contemporaneous reporting based on Maya disclosures places direct attacker extraction at roughly $1.65M–$1.76M, including about 20.83 BTC moved to the attacker’s Bitcoin address. The roughly $10.9M decline in pool value is treated separately as market/arbitrage fallout, not stolen funds.

Do not add the approximately $10.9M pool-value decline to direct stolen funds; it includes CACAO price collapse and arbitrage effects.

Why this remains unresolved

Timeline events

  • MAYANode exploit-hardening merge request opened2026-08-18

    Maya opened MAYANode merge request !835 to harden outbound matching, native transaction-ID uniqueness and theft-slash subsidy handling after the incident. The change set documents the accounting/state paths involved, but it does not by itself establish mainnet state recovery, deployment completion or trading restart.

    Root Cause Analysis PublishedHigh

    This event intentionally tracks the first-party technical remediation record instead of creating a separate pause event supported only by secondary reporting.

Evidence records

Source tiers describe evidence authority, not certainty for every claim. Tier 1 is the strongest source class; Tier 2 and Tier 3 provide progressively more secondary or supporting context. Source notes define what each record actually supports.

Known unknowns

Conflicting claims

Independent incident archive

Help maintain incident aftermath records

Support recovery, reimbursement, restart, migration, shutdown, evidence, and correction checks.

Support BIR
Record maintenance

Report a correction

Report missing evidence, incorrect dates, outcome changes, recovery details, reimbursement status, or broken links. GitHub Issues are preferred for structured review; the Google Form is available if you do not use GitHub.