Ice Phishing and EIP-712 Signature Scams

Ice phishing is a form of crypto wallet attack in which the attacker does not steal a private key or seed phrase, but instead deceives the user into signing a message that grants permission for a third-party contract to move tokens from the victim's wallet.

The term distinguishes this attack from 'hot' phishing (where credentials are stolen directly) — in ice phishing, the victim voluntarily grants the permission, often without realising what they are authorising.

The most common technical mechanism involves the EIP-712 standard, which enables 'permit' signatures — structured, off-chain messages that can authorise token spending without requiring an on-chain approval transaction and therefore without paying gas fees. When a user signs a permit message, they are creating a cryptographic instruction that allows a designated contract to spend a defined amount of their tokens. If the target contract is malicious, it can drain the authorised balance immediately after the signature is submitted on-chain by the attacker.

Because the signing step presents as a readable JSON-structured message rather than a transaction, many users treat it as low-risk. Wallets typically display permit signatures differently from transactions, and some older or mobile wallets display only a raw hex string with no human-readable context at all. Users accustomed to signing messages for login authentication may sign malicious permits without recognising the difference.

Ice phishing attacks have been responsible for some of the largest individual wallet drains in DeFi history, extracting millions of dollars from a single signature.

The attacker creates a fake protocol interface — a copy of a legitimate DEX, NFT marketplace, or lending protocol. The site is distributed via phishing links in Discord, Telegram, or search engine ads. When the user connects their wallet, the site immediately presents a signing request rather than a transaction.

The signing request is formatted as an EIP-712 permit message, technically granting the attacker's contract unlimited spending permission on one or more of the user's token balances, with a long or unlimited expiry. The displayed message may use misleading field names or appear to be a routine login or verification step.

Once the user signs, the signature is submitted on-chain by the attacker. The permit is now live, and the attacker's contract immediately drains the authorised token balance. Because the victim never submitted a transaction themselves, their transaction history shows nothing unusual at the time of the attack — making it harder to detect until the balance is already gone.

In NFT contexts, the same mechanism operates via the Seaport protocol's off-chain order signatures, which can be used to authorise transfer of an entire NFT collection if the signing context is spoofed.

Ice phishing succeeds because signing messages is a routine part of DeFi interaction — users sign for login authentication, order creation, and routine approvals constantly. The visual difference between a login signature and a permit approval is subtle, and many wallets do not clearly distinguish between them or decode the permit fields into plain language.

The absence of a gas cost reinforces the perception that the request is low-risk. Users who are cautious about high-gas transactions may not apply the same scrutiny to 'free' signing requests.

To verify your wallet and claim your airdrop, please sign the message below. This is free and does not cost gas.

Sign this message to authenticate your session on [fake DEX name]. No transaction required.

To access your NFT staking rewards, approve this signature request. Your assets remain in your wallet.

Security verification required. Sign the message to prove ownership and continue: [drainer permit].

When any interface asks you to sign a message, read every field before signing. If you see fields named 'spender', 'value', 'deadline', 'owner', or 'nonce', this is a permit signature — it is granting token spending authority. Check that the 'spender' address matches the legitimate protocol's verified contract address. Use a hardware wallet that displays the full decoded signing request. Use a wallet simulation tool such as Wallet Guard or Fire to preview what any signature will authorise.