Matcha Meta disclosed an approximately $16.8 million loss after an exploit tied to its SwapNet integration on Base, where an attacker abused existing token approvals rather than breaking Matcha’s core aggregation logic. Security firms PeckShield and CertiK corroborated the on-chain pattern—rapid swaps followed by a bridge to Ethereum—pointing to approval hygiene as the primary control failure.
The incident unfolded across January 25–26, 2026 and impacted wallets that had granted permanent allowances to SwapNet’s router at 0x616000e384Ef1C2B52f5f3A88D57a3B64F23757e, instead of using 0x’s One-Time Approval approach. In practical terms, the exploit surface sat in long-lived permissions that removed the user’s per-transfer checkpoint.
We are aware of an incident with SwapNet that users may have been exposed to on Matcha Meta for those who turned off One-Time Approvals
We are in contact with the SwapNet team and they have temporarily disabled their contracts
The team is actively investigating and will provide…
— Matcha Meta 🎆 (@matchametaxyz) January 25, 2026
How the exploit worked in operational terms
On-chain analysis attributed the event to an arbitrary call vulnerability in SwapNet router contracts, enabling transfers via already-approved allowances. The attacker effectively “replayed” existing approvals to move tokens without prompting fresh consent, turning prior convenience into immediate counterparty risk.
Transaction traces show roughly 10.5 million USDC was swapped into about 3,655 ETH and then bridged to Ethereum, compressing the response window and complicating follow-the-funds workflows. That speed profile is a textbook indicator of an approvals-first exploit path where time-to-bridge becomes the attacker’s risk-reduction lever.
Controls, remediation, and policy hardening
Matcha Meta urged users to revoke approvals granted outside 0x’s One-Time Approval contracts. For institutional operators, the takeaway is that approval management must be treated as a standing control domain—on par with key management and counterparty limits.
#PeckShieldAlert Matcha Meta has reported a security breach involving SwapNet. Users who opted out of "One-Time Approvals" are at risk.
So far, ~$16.8M worth of crypto has been drained.
On #Base, the attacker swapped ~10.5M $USDC for ~3,655 $ETH and has begun bridging funds to… https://t.co/QOyV4IU3P3 pic.twitter.com/6OOJd9cvyF
— PeckShieldAlert (@PeckShieldAlert) January 26, 2026
Operational actions to implement immediately include revoking approvals to SwapNet’s router address, shifting workflows toward one-time or capped allowances, and auditing treasury automation that may silently grant blanket permissions. If your stack uses scripts or bots to streamline routing, you need explicit confirmation gates around any approval creation or modification to prevent “set-and-forget” exposure.
Our alert system has detected a suspicious transaction involving the address 0xba15.
Wallet 0x6cAa drained ~$13.3M USDC on Base and is currently swapping funds for wETH.https://t.co/xQ9emLBtSD
— CertiK Alert (@CertiKAlert) January 25, 2026
PeckShield and CertiK framed the incident as a permissioning and UX failure rather than a Matcha core-protocol breach, which is a meaningful governance distinction. Routing-layer security and safe-by-default allowance behavior are orthogonal controls, and you need both to materially raise the attacker’s cost.
Going forward, attention will center on whether aggregators and wallets converge on safer defaults—short-lived approvals, clear prompts, and friction that is intentionally placed at the point of permission expansion. The next execution test is whether platforms reduce long-lived allowances at the UX layer and whether deeper post-mortem traces translate into hardened integration patterns for router-based swaps.