Binance impersonation scam uses GRAM transfers to demand a fake vault deposit

What the reports actually describe

According to PANews, the post reshared by Yi He described scammers using Telegram's GRAM transfer feature to send small amounts. The attached text presented itself as a Binance official announcement, claimed that Binance had been hacked and that user assets were unsafe, and directed users toward a so-called Binance vault. Those claims about account danger formed part of the reported fraudulent message. This article does not adopt them as findings about a reader's balance or the exchange's condition.

Odaily gives the same sequence: a small GRAM transfer, a false official notice and an instruction to move assets. Neither opened report specifies the amount of each transfer, a complete recipient address, the number of people contacted or verified losses. Neither supplies a transaction-level reconstruction that would establish how a particular recipient interacted with the message.

We have read the two media reports. We have not directly inspected the original social post, so no wording here is presented as a direct quotation from Yi He. This attribution matters: a report that someone reshared a warning supports describing that warning as reported. It does not support inventing additional advice in that person's voice.

The description also does not establish the technical properties of GRAM. Readers should not infer a network, contract type, wallet permission or account integration from the name alone. The useful evidence in these reports concerns the claimed sender and the demand to transfer assets.

Why an incoming message does not establish identity

Telegram's own FAQ explains that people can contact a user if they know the phone number, if the user messages them first, through a shared group or through a public username. Those contact routes do not establish the identity claimed by an incoming message. Telegram explains who can contact a user.

The jump from receipt to authority

The reported sequence gives the recipient something concrete to look at: an incoming payment and its message. The next step asks the recipient to accept a claim about who sent it. The final step asks for control over assets elsewhere. Those are separate decisions, even when the sender puts them in one screen or one paragraph.

Consider the first decision narrowly. If your own record shows an incoming transfer, it may help establish what appeared in your account. Keep that record. It does not answer whether the accompanying statement about Binance is genuine, whether the sender represents the exchange or whether the destination named in the text belongs to the exchange.

The second decision is about identity. A name or phrase inside the received message is part of the material being checked. Using that same name as the reason to trust the message would leave the identity question unresolved. Ask what independently opened channel confirms the instruction, and whether that confirmation identifies the actual action and destination.

The third decision is the transfer itself. A message calling a destination a vault provides a description supplied by the sender. Before acting, establish who controls the destination and why you are being asked to send there. The reports provide no verified vault address for readers to use. There is therefore no destination in this article to copy into a withdrawal form.

If the message has arrived but you have not acted

For a Binance-related message of this kind, complete these checks before confirming the requested transfer:

1. Save the complete message and incoming transaction record, including the visible sender and proposed destination. Keep the original record where possible.
2. Independently open the Binance account application or saved entry you already use. Through your established account support route, where available, ask whether that exact instruction and destination are genuine.

Write down the receiving time and the timezone shown by your own record. If you later describe the incident to support, distinguish the time the payment appeared from the time you saw the message. Neither establishes when the alleged sender created it. Do not replace a missing timestamp with the publication time of these news reports.

Next, open the application or saved account entry you already use independently of the message. Check whether it contains information relevant to the specific instruction. Where your existing account provides a support route, ask about the exact wording and destination. Avoid using contact details supplied only by the suspicious message as your method of confirming that message.

If no independent confirmation is available, keep the outgoing action paused. You do not need to prove every part of the sender's story false before declining an unverified request. The sender is asking you to make a transaction, and the requested destination remains unverified.

Keep an evidence record that answers a specific question

For this reported tactic, a useful record connects the incoming transfer to the instruction that accompanied it. Save the exact message text, any visible sender identifier and the destination the message asks you to use. Where the interface provides a transaction reference or address, copy it accurately into your private record. Do not guess missing characters from a shortened display.

Keep your own actions in a separate sequence. Record whether you only read the message, followed a link, entered information or submitted a transfer. These actions are different, and a support request should say which happened. The two news reports do not establish that reading a message or clicking a link alone causes assets to move.

If you made an outgoing transfer, preserve the asset, amount, network as shown in your own record, destination, time and displayed status. These are fields to collect from evidence, rather than details this article can supply. A status label should be copied as displayed; do not describe a transaction as recovered, cancelled or completed unless your evidence supports that status.

When seeking help, start with the question you need answered: whether an instruction is genuine, whether a transfer was submitted, or what a displayed status means. Include the relevant records through your established account support route. Do not place private account information in a public reply to the sender simply to demonstrate that you received the payment.

If you have already followed part of the request

Stop the sequence at the point you have reached and record it. If you have opened a page, that does not establish which permissions, if any, you granted. If you entered a destination but did not submit a transaction, record that distinction. If you did submit one, use your own transaction history to establish its status before describing the outcome.

Open your familiar account application separately and review the actions you can verify there. Ask support through the established route about the specific records. This article cannot confirm a cancellation facility, recovery route or response time for a particular transfer, so it does not prescribe an invented menu sequence.

Do not make another payment merely because the same unverified conversation now describes it as a recovery step. Apply the same identity and destination checks to each new instruction. Calling a later transfer a release fee or a correction would still leave its authority to be established. This is a proposed precaution, not a claim that the opened reports observed those additional requests.

A reader reporting a loss should keep the reported amount separate from the unexplained incoming payment. The source reports provide no total-loss figure for this tactic. Adding the small incoming amount to an alleged loss, or treating it as compensation, would require evidence that the reports do not contain.

The exchange incident and the message require different evidence

The fraudulent text reportedly invokes fears about Binance. A reader may also be following other news about the exchange. That broader concern does not resolve who controls the destination in a message received alongside a transfer. Assess the instruction on its own evidence even when its opening sentence resembles something in the news.

Our editorial reading is that the alleged safety problem and the proposed remedy need separate verification. A credible report about an exchange event would not by itself authenticate an unrelated sender's transfer request. A claim that an account needs attention should be checked from the account channel you opened independently.

For that reason, this article does not recommend moving to a different venue or buying a different asset. Neither action answers whether the received instruction came from an authorized source. The immediate task is to preserve the relevant record and avoid completing an unverified outgoing transfer.

Quick answers

Does an incoming GRAM payment prove Binance contacted me?

The reports establish no such authentication. Their central allegation is that scammers paired small payments with messages falsely presenting themselves as official notices. Treat the sender's identity as a question to verify through an independent account channel.

Did Yi He directly confirm a particular victim's loss?

The opened media reports describe a warning she reshared. They do not provide a verified victim count, an aggregate loss or a case-by-case account. We did not inspect the original post and do not attribute a direct quotation or an additional finding to her.

Can I use the destination mentioned in the message as a safety address?

The reports describe a supposed vault as part of the fraudulent pitch. They do not verify an address for readers to use. Preserve the destination as evidence and withhold the requested transfer while checking its authority.

What would change this account?

An original statement, a verified transaction record or a documented victim case could add details about the sender, destination or outcome. Those details would need their own checks. For the message currently described by the two reports, keep the full text and transaction record available when asking established support to verify the request.