Coinbase Approval Exploit: How Mis-Scoped Allowances to 0x Settler Enabled a Drain.

Summary

On August 13, Coinbase's fee-receiver wallet lost approximately $550,000 due to mistakenly granting ERC-20 allowances to 0x's Mainnet Settler, a permissionless execution contract. This wasn't a hack or exploit; it was a configuration error that handed a sophisticated MEV bot the approval to drain dozens of token types from Coinbase's treasury. The incident was first flagged by security researcher @deebeez, who provided initial analysis of the attack. Hours later, Coinbase's CSO confirmed it was an isolated issue that occurred due to changes in a corporate DEX wallet implementation; customer funds were not affected.

Also, extensive discussions were comparing the Coinbase incident with Zora’s earlier “Composability Attack,” involving 0x’s Mainnet Settler, which resulted in losses of approximately $128k and $75k. This article outlines how the Coinbase exploit unfolded, highlights the differences from Zora’s composability path, and details the controls that could have prevented or mitigated both attacks.

Understanding 0x Protocol and Why Coinbase Uses It

Before we start going into the technicalities of the incidents, let's go through some of the background of the protocol involved. 0x operates as a sophisticated execution and aggregation layer in the DeFi ecosystem, building optimal trading routes across AMMs (Automated Market Makers), RFQ makers (Request for Quote), and bridges before settling transactions atomically through their Mainnet Settler contract. When users execute swaps through Coinbase's interfaces that leverage 0x aggregation, the settlement process generates affiliate fees that flow to designated Coinbase fee wallets, explaining why these addresses regularly interact with 0x Protocol's infrastructure.

The Settler contract itself embodies a fundamental DeFi principle: permissionless execution. Anyone can call it, which enables powerful composability and innovation. However, this same openness becomes dangerous when users grant it token spending rights. 0x's documentation couldn't be clearer on this point: "NEVER set an allowance on the Settler… ONLY on Permit2 or AllowanceHolder."

Major Addresses Involved

• Coinbase Fee: 0x382ffce2287252f930e1c8dc9328dac5bf282ba1

• Exploiter: 0x17f79e70ae89c6e32a9244d3d57b7aa648246468

• Bot: 0xac13439d598cd1a60c14c965ed0fa7c46cb0d89d

Decoding the Incident

First, to clarify: there was no bug, no exploit in the code. The failure was authorization: Coinbase's fee wallet issued ERC-20 approvals to a permissionless executor (0x Settler). Once an allowance exists for (owner=CoinbaseFee, spender=Settler, token=X), any caller can instruct Settler to transferFrom and route those tokens.

Unfortunately, that's exactly what a bot did: pull, swap (often via WETH/Uniswap v3), and consolidate. Public reporting pegs the loss at roughly $300k and cites CSO confirmation/cleanup (revokes and rotation). However, Blockscope's analysis found the losses exceeded $550K.

Sophisticated bots monitor real-time Approval events to known public executors; when a high-value wallet grants broad allowances, they immediately craft Settler calls to drain funds. This isn't mempool front-running or sandwich attacks, it's exercising already-granted rights.

On-Chain Activity

Using the Blockscope Tracer, we reconstructed the entire incident flow and mapped out the movements of every token drained from the Coinbase fee wallet. Tracer 1 clearly shows the fee wallet being emptied across ~168 different ERC-20 tokens, each forwarded into various DeFi pools for swaps. These swaps consistently routed through popular AMMs, with the majority of tokens eventually consolidated into wETH.

In Tracer 2, the breadth of the operation becomes visible: the draining bot interacted with close to 180 different DeFi pools, a scatter-pull strategy designed to liquidate the diverse holdings of Coinbase’s wallet.

Each approval granted to the 0x Settler contract, tokens like AMP, MYRIA, DEXTools, Swell, and stablecoins like USDT, PyUSD, and many others, was methodically exploited. A bot EOA invoked Settler.execute(...), and internally, the flow followed a repeating pattern:

transferFrom(owner=CoinbaseFee, spender=Settler, token=X) → AMM swap → Payout to the bot’s addresses

Tracer 3 then captures the consolidation phase. After dozens of incremental drains, the outputs were simultaneously swapped into wETH and finally converted to ETH. The ETH proceeds were then deposited into the exploiter’s consolidation wallet. Alongside this activity, we can observe the bot paying priority fees (bribes) to block builders during the swaps, ensuring the draining bundles were included without interruption.

Blockscope traces highlight just how systematic the whole attack was: a broad scatter-pull of tokens, hundreds of DeFi pool interactions, followed by a consolidation funnel into ETH, all executed under the cover of validator bribes. This pattern matches the classic playbook bots use when approvals to permissionless executors cover many assets at once, fast, exhaustive, and ruthlessly efficient.

Breakdown and Timeline

• August 13, 2025, at 17:09 UTC

The very first action that enabled this incident was the Coinbase fee wallet granting approvals to the 0x Mainnet Settler contract. Using Blockscope Wallet Profiler, we observed multiple function calls where the wallet executed approve() transactions across dozens of ERC-20 tokens. When these approval transactions were decoded and examined with Blockscope’s AI Investigator, it became clear that Coinbase had given the Settler contract broad token spending rights. This misconfiguration set the stage for the subsequent drain.

First Approval Tx: 0xc4c090334cb46ca327a6d833db3dc69ecbaf38ecb29ba53ae996951d828fabe8

• August 13, 2025, at 17:10 UTC

The first transfer occurred at 17:10 when the exploiter initiated the attack by calling the 0x Settler contract and draining Coinbase's fee account for ORN (Orion Protocol) tokens. The bot immediately executed swaps to convert the tokens to ETH, transferring proceeds to the exploiter's wallet while paying bribes to block builders for priority inclusion. From that point forward, it became a continuous streak of drainage, swaps, and consolidation across multiple token types.

Tx: 0xc1fde1d472dc682bd68c4dff005d50b360c8f8fba491c636388a25b5757e3abb

• August 13, 2025, 21:35 UTC

The exploit continued for more than 4 hours, during which the bot successfully consolidated $525K worth of ETH (pure profit, excluding miner bribes and gas fees for swaps). As of now, the exploiter's wallet is holding all the funds and hasn't conducted any further operations.

Additional Findings

The exploiter's wallet was funded by a smart contract that has been labeled as a scam (0x4de23f3f0fb3318287378adbde030cf61714b2f3) on various open-source platforms and blocked by multiple centralized entities. Blockscope's Wallet Profiler has already provided comprehensive labels for the address, revealing that it was involved with Tornado Cash, appears on the OFAC sanctions list, and has been blacklisted by Tether. There is some exposure to KYC entities, which will require further analysis to identify the entity behind the operation.

Coinbase vs. Zora: Different Attack Vectors

Zora incidents were an outcome of a composability attack with no broken code involved. This attack happens when two otherwise safe systems, combined, create an unintended path for value extraction. In Zora’s case, the claim logic legitimately allowed claims to any recipient, and the 0x Settler is a public executor anyone can call. Allocations intended “for 0x” were sent to the Settler’s address; an attacker then used Settler to call Zora’s claim on Settler’s behalf and redirect the payout to their wallet.

No code was broken, each component behaved as designed, but their composition enabled ≈$128k in losses, followed by a ≈$75k reprise using the same “public, permitted functions chained together” pattern.

However, the Coinbase event was not a composability attack; it was an authorization mistake. The fee wallet approved the public Settler contract as a spender, and a bot simply used those allowances to transferFrom tokens and swapped them out. In short: Zora = safe parts combined poorly; Coinbase = mis-scoped approvals to a public executor.

Risk Management and Prevention Strategies

To safeguard against incidents like Coinbase and Zora, both individuals and institutions must adopt a layered defense strategy, combining secure protocol design, disciplined wallet policies, and continuous monitoring with advanced tools like Blockscope.

• Protocol-Level Safeguards: Design out the risk: never grant approvals to public executors/routers (especially when the docs explicitly warn against it). Use Permit2 and AllowanceHolder for scoped, time-limited spend so no standing rights live on a permissionless contract. Blockscope Smart Contract Analyzer helps you understand contract behavior and surfaces risky function paths before integration.

• Corporate Wallet Policies: Enforce a strict approval policy: maintain a spender allow-list (Permit2, AllowanceHolder, vetted bridges only) and use receive-only fee wallets with periodic sweeps to an ops wallet for swaps. Apply this via your signer/custodian policy, and enable Blockscope Watchtower and Security Monitoring alerts on any attempt to approve non-approved executors.

• Detection and Monitoring: Continuously watch for (wallet, token, spender) allowance deltas, especially to known permissionless executors. Use the Blockscope Transaction Simulator to pre-simulate call trees and ensure transactions behave as intended before broadcast.

• The Limits of Privacy Solutions: Consider encrypted mempools to mitigate sandwiching/front-running, not allowance-based drains. Once on-chain permissions exist, bots can exploit them without ever seeing your pending transactions.

Conclusion

The Coinbase loss is best categorized as allowance mismanagement amplified by a permissionless executor, a preventable operations error, not a code exploit. The Zora incidents are composability attacks: individually safe contracts that, when combined, produce an unintended extraction path. Both teach the same lesson: in a permissionless world, who you grant authority to, or which public contracts you treat as trusted recipients, matters as much as code safety.

Note: The nuance on amounts: public coverage cites ~$300k, while Blockscope data shows losses ~ $550K on the basis of valuation timestamp, inclusion/exclusion of small dust tokens, and count post-drain swaps and transfers.

Written by: Tushar Tiwari, Forensics Analyst @ Blockscope

For more information, please reach out to us at [email protected]

Disclaimer: Best Effort Investigation

This investigation and its findings represent our best effort based on the information available at the time. However, please be aware of the following limitations:

• The data used in this investigation may contain inaccuracies, omissions, or errors.

• Information sources may be incomplete or subject to change.

• New evidence may emerge that could alter the conclusions.

• Analysis and interpretations are based on current understanding and may evolve.

We have made every reasonable attempt to ensure accuracy, but cannot guarantee that all information is entirely correct or complete. This report should be considered a snapshot of our current knowledge and understanding, subject to revision as new information becomes available.