In July, the Singapore Police Force issued an advisory about a cryptocurrency scam with one deeply uncomfortable property. When the dangerous part is over, nothing looks wrong. The suspicious video call ends. No transfer appears, and the wallet balance sits exactly where it was. What left the session wasn't money, it was a signature. And a signed token permit can stay useful to an attacker for as long as its deadline allows, waiting for a moment when nobody is watching the account anymore.
That's the premise this article takes seriously. "Nothing moved" is not the same claim as "nothing was authorized," and the space between those two statements is where this scam operates. Closing that gap raises the questions the rest of this piece works through. What can a signature actually do? What does the hardware wallet really check? And what do you do in the awkward hours after a signing request felt wrong?
The chain in the advisory begins nowhere near a blockchain. It starts with a Telegram contact, then a link to a video call, then a prompt to install what looks like a software update and is actually malware. Somewhere inside that compromised session, a wallet prompt shows up looking routine, and the victim signs it. Then nothing happens. Not that day, not visibly—sometimes not for weeks.
The waiting period is a feature, at least from the attacker's side of the table. The signed permit exists off-chain, in the attacker's hands, and whoever holds a valid permit can choose when to submit it. Submitting activates a token allowance; the transfer that empties the account comes after that, at a time the attacker picks. The victim, meanwhile, has already checked the balance and, seeing nothing unusual, moved on with their week.
Big-event fraud waves work the same social channels, and SecureWorld has covered how wallet-connected scams thrive on Telegram-driven lures. What makes the permit version nastier is the delay: a phishing site that drains a wallet announces itself immediately, while a harvested signature gives the attacker a scheduling decision. One caveat worth keeping: this chain is what the advisory describes, and it's a pattern to defend against rather than a universal playbook every attacker follows.
Wallets ask you to approve several things that feel identical in the moment and are nothing alike underneath. Connecting a wallet to a dApp shares your address. Signing a plain message proves you control it. Approving a token on-chain grants an allowance and costs gas. Transferring tokens moves them. And then there's the fifth one, the subject of this article: signing an ERC-2612 permit, which is an off-chain signature that authorizes a future allowance without touching the chain at the moment you sign.
The permit's contents are less exotic than they sound. It names an owner, which is you. It names a spender, the address being authorized. It carries a value, meaning how much the spender may take, sometimes an unlimited cap. It includes a nonce, which keeps an old permit from being reused once a newer one is processed, and a deadline, after which the signature expires. The part that surprises people is the relayer behavior: the standard allows any caller to submit a valid permit, and "any caller" includes people you have never met. Once submitted, the allowance is live, and the later token movement simply uses it.
A quick vocabulary note, since the terms get blended in coverage of these scams. Permit2 is a separate mechanism, a Uniswap-built contract that manages approvals through its own system, and wallet vendors treat it as its own signature-phishing category. Related problem, different plumbing. Blur those labels together and the response steps get muddier than they need to be, which is why this piece sticks with ERC-2612 and brings up Permit2 only where the difference actually matters.
Here's the question victims ask first: how was this possible with a hardware wallet? The seed never left the device. No one saw the private key. Both of those statements can be true while the money still goes, because the device's promise is narrower than the owner's mental model of it. A hardware wallet protects the key. It signs what you approve. If what you approve is a valid authorization for someone else to spend your tokens, the device has performed flawlessly and you have still lost.
Which moves the real security boundary to the screen. The industry's term for doing this well is clear signing: translating the encoded request into intent a human can evaluate on the device's own trusted display. Action type, token, spender, amount or cap, deadline, chain. When a wallet can't decode the request, you get the blind-signing experience instead, a hash or a wall of hex, and an approve button under it. Approving information you cannot read is a coin flip dressed up as a security ceremony.
So the operating rule is short. Read the six fields on the hardware screen, not the computer's. And when the laptop says one thing and the device says another, believe the device and stop, because the disagreement is the warning.
The defensive advice most people know is "check your approvals," and it's good advice with a blind spot this scam exploits. An allowance checker reads on-chain state. An unsubmitted permit isn't on-chain state; until someone submits it, it exists only as a signature, as Revoke.cash's own tool guidance is careful to say. So a clean approval dashboard, the day after a suspicious call, proves less than it appears to. The permit may simply be waiting.
Once a permit is submitted, the picture improves: the allowance is now visible and can be reviewed and revoked like any other token approval. Note what revocation is not, though. Disconnecting your wallet from a dApp changes connection state and touches allowances not at all; those are separate systems, and plenty of people have "disconnected" their way into a false sense of safety.
As for killing a signed-but-unsubmitted permit, there's no single universal path. Some situations allow invalidating the nonce, and the mechanics depend on the account, the token contract, and the wallet involved. That's a case for current, wallet-specific guidance from official channels rather than a generic tutorial written here.
First, figure out which problem you actually have. A signature nobody has submitted yet is one situation. An allowance that's already active is a different one. Malware on the device, or a seed that's no longer secret, changes everything again. Sorting that out is the work; the sequence below keeps you from making it worse while you do.
Stop and move to a known clean environment
End the call or session and stop approving anything. Treat the device from the suspicious session as compromised until it's been isolated or cleaned, and do your investigating from a machine you trust, reaching wallet and exchange support only through addresses you already know or official sites you navigate to yourself. Ethereum.org's scam-response guidance is a sane starting checklist for this stage.
Work out what was signed and what's already visible
Reconstruct what you can from memory and screenshots. The account and chain. The token. Whichever dApp or spender was asking. The amount or cap on the prompt, the deadline if you caught it, plus any transactions or approval events that already exist. Then review active approvals and recent activity, holding onto the earlier caveat with both hands: an empty allowance list does not disprove an off-chain signature.
Contain the authorization you can actually see
Where your wallet supports cancelling or invalidating a suspected permit, follow its official steps. Revoke active approvals you don't recognize. If real risk remains, move at-risk assets to a fresh account, doing it from a known-clean device, since transferring from an infected one hands the attacker a second chance. Preserve the evidence and report the incident, both to police and to the platforms involved. And when a "guaranteed recovery" service reaches out a few days later, and one will, understand that this isn't help arriving—it's the second wave.
For teams and treasuries, the durable fix is procedural. Keep vault accounts that never touch dApps, and interaction wallets that hold only what a task needs. Keep standing allowances minimal, prefer bounded caps over unlimited ones where the workflow allows, and put approval reviews on a calendar instead of leaving them to anxiety. For any high-value or unfamiliar signing request, require a second person or an independent channel before anyone signs. Tailored social engineering is now cheap to produce at scale, as SecureWorld's look at AI-fueled phishing campaigns makes uncomfortably clear, and a lone signer on a live call is exactly the target it's optimized for.
The corollary costs nothing: nobody signs anything during an unsolicited support, sales, or video call, ever, and dApps get reached through bookmarks rather than pasted links. Where you have a choice of tooling, favor wallets and dApps that support readable intent, transaction simulation, risk alerts, and explicit spending limits.
It's worth separating the purchase stage from everything that follows, because they fail differently. When acquiring crypto, the checks are old-fashioned: the official domain reached deliberately, a payment flow that behaves as documented, a wallet destination you control and verified, and support channels that exist. Choosing a route to buy crypto safely settles that first boundary and nothing beyond it.
A legitimate purchase does not vouch for the next dApp you connect to, or for whatever spender and signature request turn up later in some mid-call prompt; each of those is its own trust decision with its own verification. And a scoping note for this article's mechanism: ERC-2612 permits apply to compatible tokens and contracts on EVM-style networks. Native Bitcoin doesn't use them, which is one more reason to know exactly which asset and chain a given prompt is talking about.
The rule that survives contact with all of this fits on a sticky note. Before approving any signature, name the action, the token, the spender, the amount or cap, the deadline, and the chain, from the trusted display, in your own words.
Can't name all six? Then stop, verify through a separate channel you chose, and let the request expire on its own deadline. The attacker's whole plan depends on you approving something you couldn't quite read. Decline that one favor and the rest of the chain never gets built.