Magic Eden y00ts indexer-bug counterfeit-listing exploit — Solana — 2023-01-04

Summary

Magic Eden is the largest NFT marketplace on Solana and operates verified-collection allowlists for NFT collections. Its verification programme is intended to give buyers a high-confidence signal that listings appearing under a verified collection page are NFTs from the genuine collection (not counterfeit deployments mimicking the genuine collection's name, art, or metadata). Through 2022 the verification programme was operative across the major Solana NFT collections including ABC and y00ts.

On 2023-01-04, an indexer bug in Magic Eden's listing infrastructure — specifically in the indexer code path used by the platform's Snappy Marketplace / Pro Trade tools — allowed unverified NFTs to be listed under verified collection pages for ABC and y00ts. Attackers exploited the bug by deploying counterfeit Solana NFTs that mimicked the verified collections' metadata and listing them through the affected indexer path; the bug's failure to enforce the verified-collection allowlist on that path caused the counterfeit listings to surface under the genuine collections' pages. Buyers browsing ABC and y00ts collection pages saw the counterfeit listings as if they were genuine and purchased them at floor-price-equivalent prices.

Across the incident window before Magic Eden detected and patched the indexer bug, 25 counterfeit NFTs were sold across 4 verified collections at 20–50 SOL each. Magic Eden detected the issue, patched the indexer, and publicly acknowledged the incident the same day. The marketplace offered SOL-denominated refunds to all affected buyers; the cost of the refunds was absorbed by Magic Eden as the marketplace operator. End-user buyers were structurally made whole post-refund.

The case is structurally distinct from the standard T12.002 sub-pattern in which a counterfeit-collection deployment relies on user search-engine-discoverable naming or front-end-side phishing to attract victims. The Magic Eden y00ts case has counterfeit listings appearing under verified collection pages on a major marketplace's verified surface — the verification badge that buyers were trained to rely on as the highest-confidence anti-counterfeit signal was bypassed by an indexer bug. This makes the case the canonical infrastructure-failure example for T12.002's verified-collection-allowlist Mitigation: the Mitigation was implemented at the marketplace, but the implementation had a per-code-path consistency gap that the attackers identified and exploited.

For OAK's purposes the case is the canonical worked example for the per-path consistency requirement on top of marketplace-side canonical-contract / verified-collection allowlists. The T12.002 page identifies allowlist enforcement at the marketplace indexer as the load-bearing Mitigation; the Magic Eden y00ts case demonstrates that the Mitigation is necessary but not sufficient absent per-path consistency, and the v0.x guidance for marketplace operators implementing the Mitigation should treat per-path allowlist-enforcement audits as a discrete sub-Mitigation.

Timeline (UTC)

When	Event	OAK ref
Pre-2023-01-04	Magic Eden operates verified-collection allowlists across major Solana NFT collections including ABC and y00ts; verification programme is mature and serves as the load-bearing buyer-side anti-counterfeit signal	(allowlist baseline)
2023-01-04 (early UTC)	Attacker(s) identify the indexer bug in the Snappy Marketplace / Pro Trade tools code path; deploy counterfeit Solana NFTs mimicking ABC and y00ts metadata	T12.002 counterfeit deployment
2023-01-04	Counterfeit NFTs listed under verified collection pages for ABC and y00ts via the affected indexer path; allowlist enforcement bypassed on the path	T12.002 verified-page contamination
2023-01-04	Buyers browsing ABC / y00ts collection pages purchase 25 counterfeit NFTs at 20–50 SOL each across 4 verified collections	T12.002 victim purchases
2023-01-04 (within hours)	Magic Eden detects the indexer bug, patches the affected code path, removes the counterfeit listings	(operator response — same-day)
2023-01-04 onward	Magic Eden publicly acknowledges the incident; offers SOL-denominated refunds to all affected buyers	(operator response — refund commitment)
2023-01-04 to following days	Refund disbursement to affected buyers; per-buyer remediation completes	(recovery)
2023-01 onward	Industry coverage cites the case as the canonical infrastructure-failure example for marketplace-side verified-collection-allowlist enforcement	(forensic record)

What defenders observed

• Verified-collection allowlist enforcement was correctly implemented at the headline level but inconsistent across indexer code paths. Magic Eden's verification programme was operative on the standard listing path; the bug was specifically in the Snappy Marketplace / Pro Trade tools indexer path, where the allowlist enforcement check was missing or incorrectly applied. The defender lesson is that allowlist enforcement is a per-path requirement, not a per-marketplace requirement. A marketplace running an allowlist must audit every indexer code path that surfaces collection listings to verify that each path enforces the allowlist consistently, including secondary tools, pro-trader interfaces, API endpoints, and aggregator-facing endpoints.
• The detection-and-response loop was operator-rapid. Magic Eden detected the bug, patched the affected path, and publicly acknowledged the incident the same day. The same-day response limited the affected-buyer count to 25 (across 4 collections); the same-day refund commitment retained buyer trust in the marketplace's verification programme and limited reputational damage. The case is a positive example of marketplace-operator response cadence even though the underlying Mitigation had a consistency gap.
• Refund as Mitigation absorbs end-user loss; reputational and structural costs remain at the operator. Magic Eden absorbed the refund cost (~$18K–$30K depending on SOL valuation across the window) and made affected buyers whole. The structural cost — the demonstrated bypass of the verified-collection allowlist mechanism that buyers were trained to rely on — is a residual cost at the marketplace-operator level even after refunds. Future T12.002 worked examples should be explicit about which costs are absorbed by which party (end-user, marketplace operator, collection issuer) and which costs (reputational, structural-trust-erosion) are not transferable.
• Per-path-consistency audits are a discrete defender practice and warrant explicit treatment. Magic Eden's post-incident response committed to additional indexer-path audits to identify and close similar consistency gaps. This is the load-bearing operator-side practice for marketplaces running verified-collection allowlists: routine audits of every indexer code path that surfaces collection listings, treating each path as an independent enforcement boundary rather than relying on the headline allowlist mechanism. The practice is currently uneven across NFT marketplaces; OpenSea has more public documentation of its detection pipeline as referenced in [openseamoderation2022], but per-path-consistency audits are a contributor target for v0.x improvement across all major NFT marketplaces.
• The case is structurally distinct from search-engine-discoverable counterfeit-collection deployments. The standard T12.002 sub-pattern (a) — counterfeit-collection deployments that rely on Unicode-lookalike naming, capital-I-vs-lowercase-l character substitution, or "Official" suffix variants to attract victims via marketplace search — is detectable at the indexing-time similarity check. The Magic Eden y00ts case is structurally different: the counterfeit listings appeared under the genuine collections' verified pages, not under similar-named-but-distinct collection pages. The Mitigation surface is therefore allowlist-enforcement-consistency, not name-similarity detection. Contributors writing future T12.002 worked examples should preserve this distinction explicitly.

What this example tells contributors writing future Technique pages

• Marketplace-side allowlist enforcement requires per-path consistency audits as a discrete Mitigation. The T12.002 page identifies "canonical-contract-allowlist enforcement at the marketplace indexer" as the load-bearing Mitigation. The Magic Eden y00ts case demonstrates that this Mitigation has a per-path consistency requirement that is often under-treated in marketplace implementations. Contributors writing the v0.x Mitigation entries for T12.002 should consider an explicit per-path-consistency-audit Mitigation that points back at this case as the canonical worked example.
• Marketplace-acknowledgement is the strongest available attribution anchor for infrastructure-failure cases. Magic Eden's public acknowledgement of the indexer bug is the load-bearing attribution evidence at the marketplace-operator layer. Future T12.002 worked examples involving marketplace-side infrastructure failures should treat marketplace-acknowledgement as the primary attribution anchor; per-attacker attribution is typically pseudonymous in cases of this class because the on-chain extraction (counterfeit-NFT deployment + listing exploit) does not require operator-identity-revealing infrastructure on the attacker side.
• Refund-as-Mitigation is a discrete operator-side response and should be documented explicitly. Magic Eden's same-day refund commitment is the canonical operator-side response pattern for marketplace-side infrastructure-failure incidents that produce small-dollar end-user loss. Contributors writing future T12.002 worked examples should be explicit about whether the marketplace operator offered refunds, the timeline of the refund commitment, and the scope of the refund (full / partial; SOL-denominated / fiat-pegged). Refund commitments are a marketplace-operator-side trust-preservation mechanism that does not transfer to the structural Mitigation surface; a marketplace can absorb a small-dollar refund cost while the underlying allowlist-consistency issue remains unfixed.
• Solana NFTs are first-class T12.002 surface, not an EVM afterthought. The Magic Eden y00ts case is a Solana incident; the v0.1 T12 Technique pages name Solana as primary chain alongside EVM but the worked-example cohort is otherwise EVM-heavy. Contributors writing future T12.002 examples should ensure Solana-side cases (Magic Eden, Tensor, Solanart) are represented at parity with EVM-side cases (OpenSea, Blur, X2Y2, LooksRare). The on-chain artefact set differs (Solana program account vs ERC-721 contract; Solana update-authority vs EVM Ownable owner), but the structural Mitigation surface (verified-collection allowlist enforcement, per-path consistency audits, refund-as-trust-preservation) is portable across chain ecosystems.

Public references

• [magicedeny00ts2023] — The Block coverage of the January 4 2023 Magic Eden indexer-bug incident; primary forensic source documenting the 25 counterfeit NFTs across 4 collections at 20–50 SOL each.
• [chainalysisnftcounterfeit2022] — Chainalysis NFT-counterfeit and rug-pull cohort framing; supplies cohort-scale context.
• [chainalysis2022nft] — primary NFT industry retrospective; cohort-scale framing.
• [openseamoderation2022] — OpenSea's May 2022 announcement of copymint detection and verification-badge expansion; cross-reference for marketplace-side moderation pipeline maturity.

Citations

• [magicedeny00ts2023] — primary forensic source; Magic Eden indexer-bug counterfeit-listing incident.
• [chainalysisnftcounterfeit2022] — cohort framing.
• [chainalysis2022nft] — primary NFT retrospective.
• [openseamoderation2022] — cross-reference for marketplace-side moderation pipeline maturity.

Discussion

The Magic Eden y00ts case is OAK's canonical worked example for the per-path consistency requirement on top of marketplace-side canonical-contract / verified-collection allowlists. The case demonstrates that allowlist enforcement at the marketplace indexer — identified as the load-bearing Mitigation in the T12.002 technique page — is necessary but not sufficient absent consistent enforcement across every indexer code path that surfaces collection listings.

The case carries additional analytical weight as the cleanest available infrastructure-failure example for the T12.002 Mitigation surface. Most T12.002 worked examples in the public record (counterfeit collection deployments at attacker-controlled domains, Discord-compromise-driven fake-mint announcements, search-engine-discoverable lookalike collections) are detectable through the standard image-perceptual-hash and metadata-similarity detection layer; the Mitigation is "implement the detection layer", and the failure is "did not implement the detection layer". The Magic Eden y00ts case sits at a different layer: the marketplace had implemented the detection layer (verified-collection allowlist) at the headline level, but the implementation had a per-code-path consistency gap. The Mitigation lesson — per-path-consistency audits — is therefore at a higher level of operational maturity than the headline Mitigation, and the case anchors that level explicitly.

The pairing with examples/2022-04-bored-ape-discord-wave.md and examples/2022-07-premint-phishing.md is the most useful within-OAK cross-reference set for the T12.002 surface. The three cases together span the load-bearing failure modes for T12.002: the Yuga / BAYC cluster demonstrates the Discord-compromise entry vector against verified-account credibility; the Premint case demonstrates the front-end-side compromise of an NFT-utility platform's mint flow; the Magic Eden y00ts case demonstrates the marketplace-side infrastructure failure of the verified-collection allowlist itself. Each Mitigation surface (operator-side credential hardening, front-end-side subresource integrity / CSP, marketplace-side per-path allowlist consistency) is distinct, and contributors writing future T12.002 worked examples should classify cases by which Mitigation surface the case reveals.

For OAK's broader credibility, the Magic Eden y00ts case is the only Solana-side T12.002 worked example in v0.1. The case balances the example set across chain ecosystems and demonstrates that the T12.002 Technique generalises across chain-specific NFT-marketplace infrastructure differences. Contributors with additional Solana-side T12.002 examples (Tensor counterfeit-listing incidents, Solanart historical cohort, Magic Eden additional incidents post-January 2023) are encouraged to submit them via PR as the v0.x example set matures.

The case also sits adjacent to the broader cohort observation that OpenSea publicly stated in early 2022 — that more than 80% of items created via its free minting tool were plagiarised works, fake collections, or spam ([openseamoderation2022]). The cohort observation establishes that counterfeit-collection deployment at scale is a structural feature of NFT marketplace infrastructure rather than an episodic incident class; the Magic Eden y00ts case demonstrates that even verified-collection allowlist mechanisms — the most aggressive T12.002 Mitigation in the public marketplace toolkit — can be defeated by per-path consistency gaps. The combined picture is that T12.002 is a continuous defender problem at the marketplace-operator layer rather than a closeable surface, and that operational-maturity Mitigations (per-path consistency audits, refund-as-trust-preservation, public-acknowledgement-cadence) are at parity in importance with the headline detection-layer Mitigations.