You Approved a Wallet Signature. The Theft Comes Later

A new breed of cryptocurrency scam lets attackers walk away with nothing — and come back weeks later to take everything.

In July 2026, the Singapore Police Force issued an advisory warning cryptocurrency users about a scam so precisely engineered that victims check their wallet balance afterward and see nothing wrong. That's not reassurance. That's the trap.

The theft doesn't happen during the suspicious video call. It doesn't happen when the malware installs. It happens later — sometimes weeks later — when nobody is watching. What left the session wasn't money. It was a signature. And in the world of blockchain permissions, a signature is a permission slip that can be cashed in on someone else's schedule.

---

The Attack Chain Starts on Telegram, Not the Blockchain

The Singapore Police Force advisory outlines an attack sequence that begins with a Telegram contact, escalates to a video call link, and ends with a prompt to install what appears to be a legitimate software update. It isn't. It's malware.

Somewhere inside that compromised session, a wallet signing prompt appears. It looks routine. The victim signs it. Then nothing happens — not that day, not visibly, and sometimes not for weeks.

That delay is a deliberate feature of the attack. The signed permit exists entirely off-chain, in the attacker's possession. Whoever holds a valid permit can choose when to submit it to the blockchain. Submitting it activates a token allowance. The transfer that empties the account comes after that, at a time the attacker selects.

The victim, meanwhile, has already checked their balance. Seeing nothing unusual, they move on with their week.

This waiting-period structure makes the permit-based scam significantly more dangerous than a standard phishing site drain. A conventional wallet-draining phishing attack announces itself immediately. A harvested signature gives the attacker a scheduling decision — and the victim no obvious reason for alarm.

Understanding the full spectrum of types of phishing attacks targeting crypto users is essential context here, because permit harvesting represents one of the most structurally sophisticated variants to emerge in recent years. What separates this version from older phishing methods is the gap between authorization and visible consequence — a gap that existing defenses were never designed to close.

How the Delay Becomes the Weapon

Most fraud detection logic — whether built into exchanges, wallets, or personal habit — is calibrated to catch anomalies at the moment of interaction. A suspicious link, an unexpected transfer, an unfamiliar approval. Permit-based attacks are specifically structured to produce no anomaly at the moment of interaction. The suspicious event and the damaging event are deliberately separated in time.

By the time the allowance is submitted and the drain executes, the victim's memory of the original session has faded. The connection between the Telegram call and the empty wallet is not obvious. This is not incidental — it is the design.

---

What a Signature Can Actually Authorize

Not all wallet prompts are equal, and the difference matters enormously here.

Connecting a wallet to a decentralized application shares your address. Signing a plain message proves you control it. Approving a token on-chain grants a spending allowance and costs gas. Transferring tokens moves them directly.

Then there is the fifth type: signing an ERC-2612 permit. This is an off-chain signature that authorizes a future allowance without touching the blockchain at the moment you sign. Its contents are specific:

• It names an owner — the signer — and a spender, the address being authorized
• It carries a value, sometimes an unlimited cap
• It includes a nonce to prevent replay attacks
• It includes a deadline after which the signature expires

The element that surprises most users is this: the ERC-2612 standard allows any caller to submit a valid permit to the blockchain. "Any caller" includes people the signer has never met. Once submitted, the allowance is live. The subsequent token movement simply uses it.

A related mechanism called Permit2 — a Uniswap-built contract managing approvals through its own system — is a separate category that wallet vendors treat distinctly. Blurring those two labels produces muddier response steps than necessary. This scam operates on ERC-2612 specifically, and the distinction is worth preserving.

The Six Fields Every Signer Must Read

Before approving any signature request, a signer should be able to name all six fields from the trusted device display — not from the connected computer screen:

1. Action type — what category of authorization is being requested
2. Token — which asset is being authorized for transfer
3. Spender — the specific address receiving the allowance
4. Amount or cap — whether the authorization is bounded or unlimited
5. Deadline — the expiry timestamp after which the permit becomes invalid
6. Chain — the network on which the authorization will operate

If any field is missing, unreadable, or described only as a hash, that is not an administrative inconvenience. That is the warning.

Understanding how different types of digital currency wallets handle signing — and the varying levels of decode capability across hardware and software options — helps clarify why clear signing standards are inconsistently applied across the industry and why users cannot assume protection by device brand alone.

---

Why the Hardware Wallet Did Exactly What It Was Told

The Narrow Security Guarantee Most Users Miss

The most common first question from victims is a reasonable one: how did this happen with a hardware wallet? The seed never left the device. The private key was never exposed.

Both statements can be true while funds still disappear, because the device's security guarantee is narrower than most users assume. A hardware wallet protects the key and signs what the user approves. If what the user approves is a valid authorization for someone else to spend their tokens, the device has performed flawlessly — and the user has still lost.

The real security boundary is the display, not the device itself. The industry term for doing this well is clear signing: translating the encoded request into human-readable intent on the device's own trusted screen. Action type, token, spender, amount, deadline, and chain — all six fields, visible before approval.

When a wallet cannot decode the request, the user gets the blind-signing experience instead: a hash or wall of hexadecimal data with an approve button beneath it. Approving information you cannot read is, in practical terms, a coin flip dressed as a security ceremony.

The operating rule is straightforward. Read the six fields from the hardware device's own screen — not the computer's. When the laptop displays one thing and the device displays another, believe the device and stop. That disagreement is the warning.

Closing the Gap Between Signed and Visible

Standard defensive advice — "check your approvals" — carries a significant blind spot this scam exploits directly. An allowance checker reads on-chain state. An unsubmitted permit is not on-chain state. Until someone submits it, it exists only as a signature. A clean approval dashboard the day after a suspicious call proves less than it appears to.

Once a permit is submitted, the allowance becomes visible and can be reviewed and revoked like any other token approval. But revocation is not the same as disconnecting a wallet from a dApp. Disconnecting changes connection state and does not touch allowances. Those are separate systems, and many users have "disconnected" themselves into a false sense of safety.

Structural Defenses for Teams and Treasuries

For teams and organizational treasuries, the durable fix is procedural:

• Keep vault accounts that never interact with dApps
• Keep interaction wallets holding only what a specific task requires
• Maintain minimal standing allowances, preferring bounded caps over unlimited ones where workflows allow
• Schedule regular approval reviews rather than leaving them to moments of anxiety

Recognizing the social engineering red flags that precede these attacks is equally important at the organizational level. Tailored social engineering is now cheap to produce at scale — a lone signer on a live call is precisely the target that approach is optimized for. Requiring a second person or independent channel before any high-value signing request adds friction that costs little and disrupts the attack chain significantly.

The corollary costs nothing: no one signs anything during an unsolicited support, sales, or video call — ever.

---

The attacker's entire plan depends on one moment: the user approving something they couldn't quite read. Before approving any signature, name all six fields — action, token, spender, amount or cap, deadline, and chain — from the trusted display, in plain language. If any field is missing or unclear, let the request expire on its own deadline and verify through a separate channel you chose yourself.

The ERC-2612 permit standard documentation published by the Ethereum Foundation provides a precise technical account of how permit functions are structured and what each parameter controls — reference material that any security-conscious user or team should consult directly.

Here is how readers can put this information to use:

• Audit active approvals now using tools like Revoke.cash and set a recurring calendar reminder to repeat the review quarterly — understanding that a clean list does not account for unsubmitted permits
• Enable clear signing on your hardware wallet and refuse to approve any request that cannot be decoded into readable fields on the device's own screen
• Establish a no-signing-during-calls policy for yourself or your organization and route all dApp access through saved bookmarks rather than links received in messages or calls