How to Recognize and Avoid a Fake STON.fi Support Bot on Telegram A closer look at one of the most effective — and least discussed — scams in the TON ecosystem: the fake support bot that reac
How to Recognize and Avoid a Fake STON.fi Support Bot on Telegram
A closer look at one of the most effective — and least discussed — scams in the TON ecosystem: the fake support bot that reaches out to you before you ever reach out to it.
Most DeFi security advice is written for the moment you're actively doing something — connecting a wallet, approving a swap, signing a transaction. It assumes you're the one initiating contact with the protocol. But some of the most damaging scams in the STON.fi and wider TON community don't wait for you to make the first move. They come to you, in Telegram, usually at the exact moment you're already a little worried about something — a stuck transaction, a swap that hasn't confirmed, a deposit that seems to have vanished. That timing is not an accident. It's the entire mechanism.
💭 If there's one sentence worth remembering from this whole piece, it's this: STON.fi will never message you first on Telegram. The moment a private message claiming to be support arrives in your inbox, you're already looking at the scam, not a step toward fixing your problem.
The fake support bot rarely appears out of nowhere. It usually shows up right after you've posted a question in an official or semi-official STON.fi group — something as ordinary as "my swap has been pending for ten minutes, is this normal?" Within minutes, sometimes seconds, a direct message arrives, and the sender's profile is built to survive a quick glance:
What makes this effective isn't sophistication — it's timing. You're already mildly anxious about your funds, and here comes someone who appears to represent the exact project you're anxious about, offering to help immediately. That combination short-circuits the skepticism most people would otherwise apply.
I've watched this pattern play out in more than one TON-adjacent community, and the thing that struck me every time wasn't how convincing the bot looked — it was how ordinary and reasonable the conversation felt from the inside while it was happening.
The opening message is almost never a big ask. "Hello, we noticed you're experiencing an issue with your transaction. Please provide your wallet address so we can check the status." That's deliberate. A public wallet address isn't secret, so handing it over feels harmless — because it technically is. It's the second and third messages, once trust has been established, where the real request eventually surfaces.
Once you've responded — and most people do, because ignoring what looks like real support when you're worried about your money feels irrational in the moment — the conversation shifts. You'll typically be told that to "resolve the stuck transaction" or "verify wallet ownership," you need to do one of a few things:
Every one of these is the scam, full stop. There is no legitimate scenario, on any protocol, where verifying a transaction or fixing a technical issue requires your seed phrase. STON.fi's actual support infrastructure has no technical need for it, because the protocol has no ability to access, freeze, reverse, or "unstick" a transaction on your behalf in the first place — that's not how a non-custodial AMM works, and no amount of official-sounding language changes that.
💭 What I find genuinely useful to sit with here isn't just "never share your seed phrase" — everyone's heard that a hundred times. It's noticing that the request is wrapped in language that sounds procedural rather than sinister. "For verification purposes," "to sync your wallet with our system" — none of that means anything technically. It's borrowed from customer-service vocabulary specifically because it doesn't trigger alarm the way "give me your password" would.
Some versions skip the seed phrase request entirely and instead send a link to a fake "wallet verification" site — a near-perfect clone of app.ston.fi on a lookalike domain. You connect your real wallet there, and the connection request itself is engineered to request a broad transaction approval disguised as a routine sync. The outcome is the same either way: funds move out, and by the time you notice, the "support agent" has already gone quiet or blocked you outright.
There's a temptation to build a long checklist of red flags — the fake checkmark, the slightly-off username, the too-fast response time — and those details are real, but they're also exactly the kind of thing scammers correct for once enough people start noticing. Chasing surface-level tells is a losing game over time.
What doesn't change, because it's structural rather than cosmetic:
The instinct that saves people isn't cleverness — it's slowing down at exactly the moment the conversation is designed to make you speed up. Scam support bots work because they compress your decision-making window between "I'm worried about my funds" and "here's someone offering to fix it right now." Introducing even a small pause — closing the chat, opening a new tab, and going directly to STON.fi's official channels yourself, rather than continuing a conversation someone else started — breaks the entire mechanism the scam depends on.
If you genuinely have a transaction issue, the safer path is always to seek help through channels you found yourself: the official documentation, the verified project Telegram or Discord you navigated to on your own, or the app interface, where transaction status can usually be checked directly without needing to trust anyone's word for it. You are never worse off for verifying independently before responding to an unsolicited message — and in every case where that message turns out to be a scam, that one habit is the entire difference between an annoying five minutes and losing your funds permanently.
None of this requires technical sophistication to defend against, which is, in a strange way, the most reassuring part of the whole situation. The scam relies entirely on urgency and borrowed legitimacy, not on any weakness in the protocol itself. Recognizing that the message shouldn't have arrived in the first place is usually enough to end it before it goes any further.
