Users interacting through Matcha Meta have been hit by the swapnet hack, which abused risky token approvals to steal funds from exposed wallets.\n\nAttack drains $16.8 million via exposed approvals\n\nBlockchain security firm PeckShieldAlert first flagged a major security incident involving SwapNet that impacted Matcha Meta users. Attackers abused existing token permissions and ultimately drained $16.8 million in crypto from affected wallets. However, the core issue stemmed from how approvals were configured, not from a direct exploit in Matcha Meta’s code.\n\nAccording to PeckShieldAlert, the breach targeted users who had altered their default Matcha Meta security settings. Instead of relying on safer, temporary permissions, these users had granted broader and more persistent access to protocol contracts, leaving assets vulnerable once an attacker discovered the exposure.\n\nHow the SwapNet exploit was executed\n\nMatcha Meta offers a One-Time Approval system that limits token access to a single transaction. This design helps contain risk by ensuring that, after execution, smart contracts no longer have ongoing authority over the user’s tokens. Moreover, it forces a fresh approval before any new spending can occur.\n\nHowever, some users disabled the one time approval disabled protection and instead granted direct, long-term allowances to individual aggregator contracts. These persistent approvals were linked to SwapNet, effectively giving its contracts continuous access to user funds across multiple transactions without additional confirmations.\n\nAttackers then targeted those permanent token approvals. Once a wallet had approved the SwapNet-related contracts, the hacker could move tokens at will, without needing new signatures from the victim. That said, this allowed entire balances to be drained quietly, as no fresh on-chain approval prompts were required from users.\n\nIn practical terms, the swapnet hack turned these broad allowances into a direct attack vector. Approvals that were meant for convenient trading became a tool for unauthorized fund transfers after the contracts were compromised or misused.\n\nOn-chain traces on Base and Ethereum\n\nOn-chain data reveals that the attacker focused heavily on the Base network. Roughly $10.5 million in USDC was swapped for about 3,655 ETH, according to early analyses. Moreover, the timing and pattern of swaps suggest a coordinated attempt to quickly convert and redistribute the stolen stablecoins.\n\nShortly after the initial swaps, the attacker began base network bridging, moving funds from Base to Ethereum. Bridging is a common technique used by on-chain thieves to complicate tracking and mix transaction histories across multiple chains, making law enforcement and analytics efforts more challenging.\n\nAdditional transaction records show large USDC transfers exceeding $13 million and direct interactions with Uniswap V3 liquidity pools. Furthermore, PeckShieldAlert’s peckshieldalert breach report estimates that the cumulative impact reached approximately $16.8 million in stolen assets after aggregating activity across the involved addresses.\n\nMatcha Meta and SwapNet reaction\n\nMatcha Meta publicly acknowledged the incident and stated that it is collaborating closely with the SwapNet team. As an immediate containment measure, SwapNet temporarily disabled its contracts to halt further exploitation and reduce the risk of additional wallets being drained.\n\nFurthermore, Matcha Meta removed the option for users to set direct aggregator allowances, which had created the opening for the attack. The change aims to ensure that future trading activity relies on more restrictive approval patterns, reducing the blast radius if a similar incident occurs again.\n\nThe platform also urged users to revoke token approvals that fall outside of 0x‘s own One-Time Approval contracts. In particular, Matcha Meta highlighted allowances linked to SwapNet’s router contract, which have now been identified as a key risk factor in the breach.\n\nOngoing investigation and user protection\n\nInvestigations into the breached wallets and associated contracts remain ongoing. Both Matcha Meta and SwapNet have pledged to provide continuous updates as they track the movement of the stolen funds and engage with security researchers. However, recovering assets in such on-chain incidents often proves difficult once funds are laundered across multiple protocols.\n\nFor now, the teams are concentrating on limiting further exposure and guiding users on safe practices. That said, the episode underlines how powerful token approvals can become a liability when misused or left unchecked, especially once a swapnet router compromised scenario emerges.\n\nIn summary, the breach shows that configuration choices around approvals are as critical as smart contract code. Users who rely on restrictive, one-time permissions and routinely audit their allowances are better positioned to withstand similar exploits targeting DeFi aggregators.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Matcha Meta users hit as swapnet hack exploits permanent token approvals to steal $16.8 million
Users interacting through Matcha Meta have been hit by the swapnet hack, which abused risky token approvals to steal funds from exposed wallets.\n\nAttack drains $16.8 million via exposed approvals\n\nBlockchain security firm PeckShieldAlert first flagged a major security incident involving SwapNet that impacted Matcha Meta users. Attackers abused existing token permissions and ultimately drained $16.8 million in crypto from affected wallets. However, the core issue stemmed from how approvals were configured, not from a direct exploit in Matcha Meta’s code.\n\nAccording to PeckShieldAlert, the breach targeted users who had altered their default Matcha Meta security settings. Instead of relying on safer, temporary permissions, these users had granted broader and more persistent access to protocol contracts, leaving assets vulnerable once an attacker discovered the exposure.\n\nHow the SwapNet exploit was executed\n\nMatcha Meta offers a One-Time Approval system that limits token access to a single transaction. This design helps contain risk by ensuring that, after execution, smart contracts no longer have ongoing authority over the user’s tokens. Moreover, it forces a fresh approval before any new spending can occur.\n\nHowever, some users disabled the one time approval disabled protection and instead granted direct, long-term allowances to individual aggregator contracts. These persistent approvals were linked to SwapNet, effectively giving its contracts continuous access to user funds across multiple transactions without additional confirmations.\n\nAttackers then targeted those permanent token approvals. Once a wallet had approved the SwapNet-related contracts, the hacker could move tokens at will, without needing new signatures from the victim. That said, this allowed entire balances to be drained quietly, as no fresh on-chain approval prompts were required from users.\n\nIn practical terms, the swapnet hack turned these broad allowances into a direct attack vector. Approvals that were meant for convenient trading became a tool for unauthorized fund transfers after the contracts were compromised or misused.\n\nOn-chain traces on Base and Ethereum\n\nOn-chain data reveals that the attacker focused heavily on the Base network. Roughly $10.5 million in USDC was swapped for about 3,655 ETH, according to early analyses. Moreover, the timing and pattern of swaps suggest a coordinated attempt to quickly convert and redistribute the stolen stablecoins.\n\nShortly after the initial swaps, the attacker began base network bridging, moving funds from Base to Ethereum. Bridging is a common technique used by on-chain thieves to complicate tracking and mix transaction histories across multiple chains, making law enforcement and analytics efforts more challenging.\n\nAdditional transaction records show large USDC transfers exceeding $13 million and direct interactions with Uniswap V3 liquidity pools. Furthermore, PeckShieldAlert’s peckshieldalert breach report estimates that the cumulative impact reached approximately $16.8 million in stolen assets after aggregating activity across the involved addresses.\n\nMatcha Meta and SwapNet reaction\n\nMatcha Meta publicly acknowledged the incident and stated that it is collaborating closely with the SwapNet team. As an immediate containment measure, SwapNet temporarily disabled its contracts to halt further exploitation and reduce the risk of additional wallets being drained.\n\nFurthermore, Matcha Meta removed the option for users to set direct aggregator allowances, which had created the opening for the attack. The change aims to ensure that future trading activity relies on more restrictive approval patterns, reducing the blast radius if a similar incident occurs again.\n\nThe platform also urged users to revoke token approvals that fall outside of 0x‘s own One-Time Approval contracts. In particular, Matcha Meta highlighted allowances linked to SwapNet’s router contract, which have now been identified as a key risk factor in the breach.\n\nOngoing investigation and user protection\n\nInvestigations into the breached wallets and associated contracts remain ongoing. Both Matcha Meta and SwapNet have pledged to provide continuous updates as they track the movement of the stolen funds and engage with security researchers. However, recovering assets in such on-chain incidents often proves difficult once funds are laundered across multiple protocols.\n\nFor now, the teams are concentrating on limiting further exposure and guiding users on safe practices. That said, the episode underlines how powerful token approvals can become a liability when misused or left unchecked, especially once a swapnet router compromised scenario emerges.\n\nIn summary, the breach shows that configuration choices around approvals are as critical as smart contract code. Users who rely on restrictive, one-time permissions and routinely audit their allowances are better positioned to withstand similar exploits targeting DeFi aggregators.