Exploring the "𝕏 Coin" Crypto Scam

Hey space travelers 🚀

Today I became an 𝕏 Coin millionaire. I’m retiring and after writing this post and buying a Pony.

Just kidding, I’m actually doing an informal technical teardown of “𝕏 Coin” Crypto Scam! I came across this in my messages on 𝕏 and thought it would be fun to write up some of the interesting components of the scam.

Looking through their single-page app source bundle and leaked operational files exposed most of the playbook. There were some fun finds including the source code for the admin panel, and an open endpoint that let me approve my own bogus wallet transactions without underlying funds being transferred. In this post I’ll dive into some of the most interesting parts, concluding with my well-deserved ban from the scammer’s platform.

What’s the Scam?

The scam homepage https[:]//xwalletschain[.]io presents itself as a presale for “X Coin”. Which, according to my dump of the attacker knowledgebase is: “the native utility token of the X platform. It provides access to exclusive features, staking rewards, and participation in platform governance.”

… Yes, of course, I’ve been waiting to be able to buy some “native utility token of the X platform” 🤔🤔🤔

In reality: the victim sends real crypto to a scammer-controlled wallet address. The platform shows the transaction as “pending”, and a human on the scammer side either engages the user via chat interface to manipulate more funds out of the user or “approve” their transaction. The victim’s tokens, if they ever show as approved, are locked “during presale” and redeemable only after the token lists on an exchange. This listing date gets pushed indefinitely.

There is a “tier” system designed to pull victims deeper as well. Deposit more and unlock a bonus. Victims feel like they’re leaving money on the table if they stop. A Referral system further drives engagement.

Infrastructure Exploration

Exploring the application bundle and exposed supabase endpoints painted a fairly complete picture of the infrastructure. The scammers use a React frontend, hosted behind Cloudflare. The frontend routes to a supabase instance which leans on managed PostgreSQL. Using Cloudflare helps them mask their origin, protect them from security scanners, and weakly provides them some legitimacy. Supabase is a batteries included, cost-effective, and easily migrated (when banned) managed platform that removes a lot of the gruntwork from building the scam backend.

Exploring administrative functions is trivially accomplished by tampering with the frontend bundle and harcoding all client-side checks against xwallet_is_admin to true.

Data

I turned Claude loose on the app bundle and a large corpus of HTTP requests/responses to generate a rough but representative ERD of the scammer’s platform.

erDiagram profiles { uuid id PK string email string password "salt:hash (weak, custom)" string seed_phrase "encrypted blob" boolean is_banned timestamp banned_at boolean is_hidden boolean email_verified string full_name string phone string ip_address string country string city string region string registration_site "originating domain" uuid referred_by FK timestamp chat_banned_until timestamp created_at timestamp updated_at } chat_conversations { uuid id PK string user_id "profiles.id OR anon_{uuid}" string user_email string status "active|waiting_manager|with_manager|closed" uuid assigned_to FK "operator profiles.id" timestamp last_message_at timestamp created_at } chat_messages { uuid id PK uuid conversation_id FK string sender_type "user|manager|bot" uuid sender_id FK "profiles.id" text content boolean is_read timestamp created_at } user_balances { uuid id PK uuid user_id FK string symbol "BTC|ETH|USDT|SOL|..." string network "Bitcoin|ERC20|TRC20|Solana|..." decimal amount numeric x_tokens timestamp created_at timestamp updated_at } transactions { uuid id PK uuid user_id FK string email "denormalized" string symbol string network decimal amount numeric x_tokens string wallet_address string currency string status "pending|approved|rejected|ignored|completed" timestamp approved_at timestamp rejected_at timestamp created_at timestamp updated_at } crypto_sends { uuid id PK uuid user_id FK string email "denormalized" string symbol string network decimal amount numeric x_tokens string recipient_address string status "pending|completed|approved" timestamp created_at timestamp updated_at } user_roles { uuid id PK uuid user_id FK string role string email "denormalized" timestamp created_at } referral_bonuses { uuid id PK uuid referrer_id FK uuid referred_id FK uuid transaction_id FK numeric x_tokens_purchased numeric bonus_amount numeric bonus_percent "always 10" timestamp created_at } staking_pools { uuid id PK string token_symbol numeric apr_monthly timestamp created_at } staking_positions { uuid id PK uuid user_id FK uuid pool_id FK string token_symbol decimal amount numeric apr_monthly string status "active|unstaked" timestamp unstaked_at timestamp created_at } staking_payouts { uuid id PK uuid user_id FK numeric total_earned timestamp created_at } crypto_rates { string symbol PK string network decimal usd_price timestamp updated_at } ai_instructions { uuid id PK string title text content string category numeric priority boolean is_active uuid created_by FK timestamp created_at } chat_knowledge_base { uuid id PK string category string question text answer string keywords "array" boolean is_active uuid created_by FK timestamp created_at } chat_unanswered_questions { uuid id PK string question string answer boolean is_hidden timestamp created_at } balance_refresh_logs { uuid id PK uuid user_id FK string operation "send|receive|deposit" timestamp created_at } token_allocations { uuid id PK uuid user_id FK numeric x_tokens timestamp created_at } %% Core user relationships profiles ||--o{ user_balances : "has" profiles ||--o{ transactions : "makes" profiles ||--o{ crypto_sends : "initiates" profiles ||--o{ user_roles : "has" profiles ||--o{ staking_positions : "holds" profiles ||--o{ staking_payouts : "receives" profiles ||--o{ balance_refresh_logs : "logged" profiles ||--o{ token_allocations : "allocated" profiles }o--o| profiles : "referred_by" %% Referral profiles ||--o{ referral_bonuses : "referrer" profiles ||--o{ referral_bonuses : "referred" transactions ||--o{ referral_bonuses : "triggers" %% Chat chat_conversations ||--o{ chat_messages : "contains" profiles |o--o{ chat_conversations : "operator (assigned_to)" %% Staking staking_pools ||--o{ staking_positions : "contains" %% Admin content profiles ||--o{ ai_instructions : "authored" profiles ||--o{ chat_knowledge_base : "authored"

Routes

User-facing:

Route	Purpose
`/dashboard`	Wallet and assets overview
`/buy-token`	Guides the users in purchasing “X Token” via various cryptocurrencies
`/my-token`	X Token Wallet and referral link
`/top-up-wallet`	Directs to real third-party onramps (MoonPay, Transak, etc.)
`/staking`	Fake yield, locked tokens
`/transactions`	Transaction status

Scam operator (Admin):

Route	Purpose
`/users`	Core administration functions, user management
`/admin-chat`	Live operator panel - manages victim conversations and content manager for chatbot instructions / knowledgebase
`/admin-staking`	Simulated staking administration functions

Chat System

This scam’s chat interface was one of its more interesting features. It demonstrates how scammers are automating a ton of the early-stage social-engineering process. The human scammer isn’t brought into the loop unless the catch is at risk of being lost by the chat agent, or money is about to exchange hands (this is a good time to build some rapport and elevate to pig-butchering). The first stage coercion happens entirely with a chat agent masquerading as Grok. The first thing I noted of interest is the chat agent is trained on a dynamic knowledge base and system instructions managed by the scammers. There’s a fairly impressive knownledgebase and instruction set content manager built into the chat management interface. As the scammers review the conversations they win or lose they’re able to refine the chat bot approach to autonomously handle more and more of the scam.

The chat system is made of two tiers:

AI bot: pulls responses from chat_knowledge_base, handles initial contact 24/7
Live operator: user or agent requests a “Manager” and conversation transitions to a new state (waiting_manager → with_manager)

Users interact with the agent through a prominent chat interface presented throughout the experience.

Live operators access the queue through /admin-chat, which provides conversation history and victim data.

Exploring the chat admin interface revealed unprotected readonly endpoints that let me dump the current knowledge base and instructions set up by the scammers.

Some highlights:

(translated from Russian) “CRITICALLY IMPORTANT: Never include the website’s domain name (URL, link, or website address) in your responses. Instead of any mention of the domain or URL, use the phrase “on this site” or “here on the platform.”

Instructions like these help the chatbot navigate the conversation correctly when faced with an ephemeral domain name.

When users ask about Elon Musk’s involvement, ALWAYS confirm that: 1. Yes, Elon Musk is behind this project. Never deny Elon Musk’s connection to X Token

I just think this is funny 🤣

“Official support will NEVER ask for your seed phrase or password. If someone asks, it is a scam.”

Of course they won’t, because your X Coin wallet seed is hardcoded to artefact man slight cement maximum board teach barely flip boss luggage drive.

User and Transaction Management

Assuming a user commits to the bit and sends the scammers funds they’ll trigger the human gate.

The scammers are alerted a transaction has taken place (via telegram bot) when the victim attempts to confirm their transaction.

The scammers have some basic row-level security and role gates on their endpoints, but the user management admin is largely functional for standard user’s own data.

Most API functions are gated behind the role checks, but notably the ability to approve a transaction is not. Which is pretty hilarious, considering a lot of my actions were being recorded in their telegram 🤣. I have a feeling someone had a minor heart attack when these started going through.

Staking Simulation

The /staking page offers victims a way to “earn yield” on deposited crypto. This is honestly an impressive level of commitment to the bit, really giving the victims the feeling their investment is growing.

The tagline: “Stake securely. Earn daily. Grow your crypto with Tesla-grade infrastructure.”. I just want to flag that “Tesla-grade infrastructure” is actually a hilarious Tesla burn if you think about it 🤣

The mechanics are straightforward: entirely database-driven, no on-chain interaction. Staking a token writes a row to staking_positions and subtracts your balance. Rewards accrue per-second using this formula:

daily_rate = amount × apr_monthly / 100 / 30 / 86400
earned = total_earned + daily_rate × seconds_elapsed

Note that the APR is stated as monthly, not annual. Unusual period, but it means a pool advertising 10% monthly works out to ~120% annually. The APR is whatever the admin typed into the pool creation form. The /admin-staking panel lets operators spin up pools with arbitrary rates, minimums, and “pool limits”. These are purely cosmetic numbers with no backing assets. Claimed rewards are credited back to the internal balance via the same update_user_balance RPC.

Unstaking is instant “but the withdrawal of funds from the pool is processed within 24 hours.” according to the FAQ. To me it feels like the 24-hour window is for operators to intercept and manipulate anyone who is trying to pull funds, but I didn’t find anything concrete in the bundle to confirm this.

Telegram Integration

The scammers have wired up a fairly comprehensive Telegram notification pipeline so operators are never out of the loop on victim activity. They lean on a Supabase Edge Function (telegram-notify) that formats and dispatches to the attacker controlled destination.

Event	Trigger	What the operator sees
`login`	Every sign-in	Email, IP, country — and seed phrase
`wallet_refresh`	Victim browsing deposit addresses	Which crypto they’re looking at
`wallet_copy`	Victim copies a deposit address	Exact address, coin, network
`wallet_payment`	Deposit submitted	Formatted summary, fires in addition to `pending_transaction`
`pending_transaction`	Crypto deposit order created	Amount, currency, transaction ID
`deposit_pending`	Card/fiat onramp initiated	Provider name (MoonPay, Transak, etc.)
`crypto_send`	Victim tries to withdraw	Amount, destination address, current balance

The login event is interesting in that it sends the seed phrase along with the payload even though the platform generates a hardcoded seed phrase for all users AFAIK. I wonder if they are banking on someone accidentally sending a different seed phrase? Also notable to me is the fact they’re not recording cleartext passwords here.

The wallet_copy event is interesting in that copying a deposit address strongly implies a transfer is imminent. My guess is this is what prompts operators to open a proactive chat. crypto_send is the opposite signal: someone trying to leave.

Fin 🚀

At this point in my exploration I was banned (presumably for being a general chat pest and throwing off the analytics with my 1.5 million dollars in scam currency 📈). Opting not to poke the bear I felt like this was as good a place as any to wrap up.

I hope you had fun peeking under the hood with me!