On September 25, a whitehat researcher using the handle 0xQuit moved 3,832 NFTs out of wallets that their owners had, in several cases, not touched for months. The transfers settled at zero ETH. No signatures were requested. No malware was installed. No seed phrase was compromised. Every wallet involved had, at some point, done something entirely reasonable: it had clicked "approve" on an NFT marketplace that no longer exists.
That is the part worth pausing on. The marketplace — Magic Eden's EVM deployment — had already shut down. It had announced the end of its Ethereum and EVM support. To the user, "the platform is gone" reads as "the risk is gone." On-chain, the opposite was true. The permission survived the product. Revoke.cash published the warning; the wallets were still exposed; and the number 3,832 is almost certainly not the whole story.
The mechanism here predates this incident by seven years. ERC-721 and ERC-1155 define an operator approval — setApprovalForAll — that grants a single address the authority to transfer every token of a given collection held by the approving wallet. It is a binary switch, not a per-transaction contract. It has no expiry. It has no automatic revocation on inactivity. It has no awareness of whether the counterparty is still a functioning business.
Magic Eden's EVM users granted that authority to Limit Break's Payment Processor, a payment and royalty-distribution contract suite associated with Gabe Leydon's gaming ecosystem. Version 2 was deployed on Ethereum. Version 3 was deployed on ApeChain, the ApeCoin-ecosystem Layer 3. Both are separate deployments with what appears to be a shared code lineage — which matters more than the headline suggests. Revoke.cash flagged the issue and shipped an exploit checker so users could test their own addresses. The advice, correctly, was to check the approval itself rather than scroll back through transaction history.
Here is the quiet part: nothing in that paragraph is unusual. This is how nearly every NFT marketplace has operated since 2021.
Let me be precise about what the "0 ETH sale" detail tells us. When a transfer executes with zero consideration and without a fresh signature from the token owner, the call path almost certainly ran through an already-approved operator slot — either a direct transferFrom invoked by the approved address, or a marketplace-style settlement function that reads a pre-existing approval instead of validating a new one. The absence of a signature is the signature. If the attacker had needed a fresh EIP-712 payload, we would be reading a phishing story. We are not.
Based on my audit experience, this is the class of bug that hides in plain sight because it doesn't look like a bug. In 2017, while the ICO market was arguing about tokenomics, I spent two months tracing EVM opcode execution across fifty ERC-20 contracts. I found twelve reentrancy patterns in early DeFi prototypes before any firm had audited them. None of those were cryptographic failures either. They were logic-order failures — the contract did the right thing in the wrong sequence. Residual authority is the same genus: correct behavior, wrong lifetime.
The structural mismatch is easy to state and hard to fix. A centralized marketplace's service lifecycle is measured in quarters. An on-chain approval's lifecycle is measured in perpetuity. There is no handshake between the two. When Magic Eden exited EVM, no contract event fired saying "revoke everything you granted us." When Limit Break stopped actively maintaining a processor, no timelock expired. Two independent lifecycles, zero coupling.
My 2020 audit of Uniswap V2's core liquidity contracts taught me something adjacent: the dangerous edge cases are rarely in the happy path. We found three impermanent-loss calculation edge cases that only mattered for large LPs under specific ratio movements. Nobody notices those until someone does. Dangling approvals are the same — inert for years, then suddenly load-bearing.
There is also the cross-chain dimension, and it deserves more attention than it is getting. If Payment Processor V2 and V3 share logic, then a flaw exploitable on Ethereum is presumptively exploitable on ApeChain. Revoke.cash's warning did not confirm losses on both chains. That absence of confirmation is not reassurance; it is an unmeasured surface. ApeChain users who never touched Ethereum's V2 still hold an independent, separately deployed exposure. Cross-chain deployments multiply the attack surface without multiplying the user's awareness of it. Trust is not given; it is computed and verified — and most users were never given the tools to compute it.
Compare the alternatives that exist. Seaport and Permit2 moved the ecosystem toward signature-based authorization: each grant carries a deadline, a nonce, a specific payload. Revocation is implicit because the authorization was never standing. That model is not flawless, but it fails closed. setApprovalForAll fails open, and it fails open forever.
And revocation has a price. Every revoked approval costs gas. For a wallet holding $40 of NFTs, spending $6 to remove an exposure that may be worth nothing is a rational decision to do nothing. The security advice is correct and economically irrational for precisely the users who can least afford to ignore it.
The information gap is the real deliverable here, and it is being underweighted. No independent audit of Payment Processor V2 or V3 has been referenced. No root-cause disclosure has been published. We know a transfer happened; we do not know which function permitted it. Was it an arbitrary-transfer path in the settlement logic? A signature-validation bypass? Or simply the intended behavior of a pre-approved batch-listing flow being pointed at wallets that forgot they had opted in? Those three hypotheses imply three different remediation stories, and the industry is currently treating them as one.
I ran into a version of this problem in 2021, when I worked with three digital artists in Taipei to audit the metadata storage of high-value NFT collections. We found that roughly 30% of them stored critical image data on centralized servers. The lesson then was the same as the lesson now: the thing users believe is durable is frequently the most fragile layer. A token can be permanent on-chain while everything that gives it meaning lives somewhere that can be switched off.
The story being told is a rescue story, and rescues are comfortable narratives. I want to name the blind spot.
A single whitehat wallet now custodies 3,832 NFTs. That is not a security outcome; it is a transfer of custodial risk from a vulnerable contract to an unverified individual. There is no multisig, no timelock, no published escrow contract I have seen referenced. The entire remedy rests on one person's continued goodwill and operational competence. If that key leaks, we do not get a story about a vulnerability. We get a second incident, larger than the first, wearing a white hat.
Then there is the number everyone is quoting — 3,832 — which counts only what the whitehat moved. The blackhat transfer volume is unknown. A gap between vulnerability discovery and public warning existed. The math whispers what the network shouts, and right now the network is shouting about a rescue while the math is silent on the losses.
And beneath all of it sits an uncomfortable fact: this is not a new vulnerability. It is an old architecture being re-priced by time. Every marketplace that has shut down, migrated chains, or abandoned a deployment has left the same strata behind. The legal question has no clean answer either: moving assets without an owner's signature is, viewed strictly, an unauthorized disposition of someone else's property — performed for good reasons, but not obviously lawful ones.
The next wave of losses will not come from broken cryptography. It will come from permissions that outlived their purpose, deployed across chains by teams that moved on, held by users who reasonably assumed that "shut down" meant "safe." Proving truth without revealing the secret itself is the promise of zero-knowledge systems. Preserving safety without remembering your own approvals is the obligation we have not yet built. The question is not whether Magic Eden's users were careless. It is why a standard that has existed since 2018 still has no native expiry.
