Squid Game Token (SQUID)
See the evidence before you trust the verdict.
Historical Investigation
The contract is still live on BSC. As of 2026-07-10 it has 102,070 holders and $187K in DEX liquidity - participants trading a token from a confirmed rug pull. The deployer address retains 8.13% of supply. The rug verdict is based on confirmed historical evidence, not current engine score.
Squid Game Token was a documented rug pull executed on November 1, 2021. The deployer drained approximately $3.4M from the PancakeSwap liquidity pool. The contract contained transfer logic that prevented holders from selling their tokens. The 97/100 CRITICAL verdict shown here is the historical verdict based on confirmed evidence - the drain transaction, MARBLES mechanism, and deployer patterns - not the output of the current engine. A live scan on 2026-07-10 returns 13/100 LOW: EVM bytecode analysis cannot detect an application-layer sell restriction or reconstruct confirmed historical events. This example demonstrates exactly where contract analysis ends and entity intelligence begins.
Confidence per domain, not a single score.
Incident
Attribution
Loss
Recovery
How the incident unfolded
Late October 2021
Token launches riding the Squid Game name
SQUID launches on BNB Smart Chain marketing itself off the Netflix series, with a "play-to-earn" pitch and a MARBLES companion token. Netflix confirmed it had no affiliation with the project. The website and whitepaper carried no verifiable team identity.
Contract deployment on BscScan; contemporaneous press coverage; Netflix statement of no affiliation
October 26-31, 2021
Price surges while sells silently fail
The price runs from under a cent toward thousands of dollars as buyers pile in. Holders attempting to sell fail: the _transfer function requires a MARBLES balance to sell SQUID, and retail holders had none. Price-tracking sites added warnings that users were reporting they could not sell.
Verified in evidence table: transfer-function sell restriction (bytecode), MARBLES distribution (holder data)
November 1, 2021
Deployer drains the liquidity pool
The deployer withdraws approximately $3.4M in BNB from the PancakeSwap V2 pool. The token price collapses by over 99.99% within minutes. The project website and social channels go dark.
Verified in evidence table: liquidity drain event (on-chain transaction history, confidence 100)
2021 - present
Contract stays live; trading never fully stops
The contract was never destroyed. As of the 2026-07-10 scan it has 102,070 holders and roughly $187K in DEX liquidity - participants still trading a token from a confirmed rug pull. The deployer address retains 8.13% of supply.
Live scan snapshot 2026-07-10 (holder count, liquidity, deployer balance)
What the evidence shows
Ownership
Anonymous deployer - no attribution
Deployer address has no entity label in the registry. Project team was pseudonymous.
Mint Authority
Active - deployer retained full mint control
Ownership was never renounced. Mint authority remained with the deployer throughout.
Liquidity
Pool drained 2021-11-01; re-liquified post-rug
PancakeSwap V2 pool was drained by deployer in Nov 2021. As of 2026-07-10 the pool shows $187K in liquidity and an LP "lock" claiming 90.4% locked - but the lock expiry timestamp is 1970-01-21 (near-zero unix timestamp), an expired fraudulent lock the engine reports as safe.
Holder Attribution
Top wallets trace back to deployer; creator holds 8.13%
Creator address retains 8.13% of total supply. Top single holder (16.97%) has no entity label. 5.14% in burn address. Gate.io exchange holds 2.15%.
Proxy / Upgradeability
Upgradeable proxy detected
Engine confirms proxy pattern (has_proxy: true). The ability to upgrade the implementation is an additional unattributed control surface. Source code is not verified on BSCScan.
Transfer Controls
Anti-sell mechanism in transfer logic
The _transfer function required callers to hold a separate MARBLES token balance to sell. Retail holders had none.
What XemaS found
The SQUID token was deployed on BNB Smart Chain in October 2021, positioned as a play-to-earn game tied to the Squid Game Netflix series. The contract was not associated with or authorised by Netflix. The deployer address was never attributed to any named entity. Ownership of the contract was not renounced at any point before or after the rug event. As of the live scan on 2026-07-10, the deployer address still holds 8.13% of total supply.
The contract's _transfer function contained a dependency on a separate MARBLES token balance. To sell SQUID, a caller was required to hold a sufficient MARBLES balance. MARBLES were only obtainable through the game the developers controlled. In practice, this meant retail buyers could buy SQUID freely but could not sell it. This is the defining characteristic of an application-layer honeypot: asymmetric transfer baked above the EVM, not into the bytecode. This is why a live engine scan today returns is_honeypot: false - the EVM-level transfer logic passes all standard checks.
Liquidity was added to a PancakeSwap V2 pool without any genuine lock. On November 1, 2021, the deployer drained the BNB from the PancakeSwap liquidity pool. The SQUID price collapsed from approximately $2,861 to near zero within minutes. Retail holders were left with tokens they could not sell and a pool with no liquidity. The pool has since been re-liquified by new participants; as of 2026-07-10 it holds approximately $187K. The engine currently reports 90.4% of LP as "locked" in a dxsale presale locker - but the locker contract's unlock timestamp is 1970-01-21 (a near-zero unix timestamp, set before Bitcoin existed), making it an immediately redeemable fraudulent lock. The engine does not validate lock expiry dates, and reports is_safe: true.
A live scan on 2026-07-10 produced a 13/100 LOW verdict - the same score as Aave. The investigation identified at least two important coverage gaps contributing to that result: the application-layer MARBLES sell restriction is outside current bytecode analysis, and LP lock expiry is not yet validated. There may be other contributing factors not yet identified. The 97/100 CRITICAL historical verdict is not the output of the current engine. It reflects confirmed historical evidence - the drain transaction, deployer identity patterns, the MARBLES mechanism documented at time of rug - that contract-level EVM analysis alone cannot reproduce. Entity intelligence and historical context are what separate an on-chain contract score from a confirmed rug verdict.
Where the value went
The value flowed in one direction: buyers' BNB accumulated in the PancakeSwap pool during the surge, and the deployer removed it in a single drain event. Because the sell restriction prevented holders from exiting, nearly all invested value was still in the pool when it was drained.
| Step | Movement |
|---|---|
| 1 | Buyers swap BNB for SQUID; BNB accumulates in the PancakeSwap V2 pool |
| 2 | Deployer withdraws the pool's BNB side |
| 3 | Proceeds move onward from the deployer address |
Downstream impact
PancakeSwap (venue, not at fault)
The rug was executed through a standard PancakeSwap V2 liquidity pool. The DEX functioned exactly as designed; the malicious control lived in the SQUID token contract and its liquidity ownership. Venue and threat are distinct here - the entity holding the LP tokens governs the outcome.
Who was involved
Deployer cluster
Deployed the contract, retained ownership and mint authority, held the MARBLES supply that gated selling, and executed the liquidity drain. Majority of top-10 holders trace funding back to this cluster within 2 hops. Still holds 8.13% of SQUID supply.
Attribution: anonymous - no entity label match (see evidence table)
Project front (website, whitepaper, socials)
Pseudonymous team presenting a fabricated affiliation with the Netflix series. All channels were abandoned at the drain. No real-world identity was ever verified on-chain or off.
Why it matters
Every red flag in this contract was detectable on-chain before the rug. The transfer function dependency on MARBLES was visible in the contract bytecode and ABI. Ownership was not renounced, meaning the deployer retained full control. Liquidity was not locked, meaning it could be withdrawn at any time. The absence of any of these checks - ownership renounced, liquidity locked, transfer logic audited - was sufficient cause to avoid this token.
Evidence table
| Fact | State |
|---|---|
| Contract ownership state | VERIFIED |
| Deployer address attribution | UNVERIFIED |
| Transfer function sell restriction | VERIFIED |
| MARBLES token distribution | CONFLICTED |
| Liquidity lock status | CONFLICTED |
| Liquidity drain event | VERIFIED |
| Top-10 holder funding paths | CONFLICTED |
| Mint authority state at rug | VERIFIED |
| Sanctions match | VERIFIED |
What was not visible
Live scan returns 13/100 LOW - same as Aave
A fresh engine scan on 2026-07-10 returns 13/100 LOW. The application-layer MARBLES sell restriction leaves no EVM trace - standard bytecode analysis cannot detect it. This is the defining limitation of contract-only analysis for application-layer honeypots.
LP lock expiry not validated by engine
The engine reports 90.4% of LP as locked and marks is_safe: true. The lock expiry timestamp is 1970-01-21 (near-zero unix timestamp, pre-Bitcoin), making it immediately redeemable. The engine does not currently validate lock expiry dates against the current block timestamp. This is an open coverage gap.
Off-chain identity of deployers
XemaS cannot identify who controlled the deployer addresses. The team was pseudonymous. No real-world attribution is possible from on-chain evidence alone. The deployer still holds 8.13% of supply.
MARBLES distribution is partial
The full MARBLES holder distribution was not enumerated. The conflict rating on MARBLES control is based on a sampled subset of top wallets.
Legal status is off-chain
Whether any jurisdiction has filed charges related to this rug pull is not verifiable on-chain. XemaS does not make legal determinations.
What this incident teaches
Application-layer honeypots leave no bytecode trace
The MARBLES sell gate lived in application logic, invisible to standard EVM bytecode analysis. A contract-only scan cannot see it - which is why the live engine scores this token 13/100 LOW while the historical verdict is 97/100 CRITICAL. Where contract analysis ends, entity and behavioral intelligence has to begin.
A liquidity lock is only as good as its expiry
The engine sees 90.4% of LP "locked" - with an expiry timestamp of 1970, meaning immediately redeemable. Checking that a lock exists is not the same as checking that it binds. Validate duration and expiry, not presence.
Borrowed brand equity is not verification
The project borrowed the Squid Game name and let hype do the verifying. The affiliation was fabricated and denied by Netflix. Popularity metrics answer a different question than provenance does.
Confirmed history outranks a clean current scan
This contract would pass many present-day automated checks. The drain transaction is permanent evidence. When historical evidence and a live score disagree, the evidence governs - certainty only grows through verified evidence, never through the passage of time.
Scan any address with the same evidence engine
EVM, Solana, Bitcoin, and Tron. Every scan returns verified evidence, not a traffic-light score.
Scan a token or walletNo account required for a first scan.