Malicious Signatures and Permit Phishing

    Reviewed and updated September 18, 2026 by the SmartCryptoEarnings editorial team · editorial policy

    Signing is not the same as sending. A wallet can produce a signature that changes nothing on-chain at that moment, yet hands someone a piece of data they can submit later to move your tokens. That gap between signing and settlement is what permit phishing exploits.

    This page is about the authorisation itself: which kinds exist, what each one can do, and how to work out which one you are being asked for. The step-by-step routine at the prompt lives on the pre-signing page and is not repeated here.

    Signature now, transfer laterWhy a permit-style signature can look like nothing happened.
    1. Step 1You signA typed-data request is approved. No gas is charged and no transaction appears in your history.
    2. Step 2They hold the signatureThe signed message is a portable authorisation. It sits with whoever requested it.
    3. Step 3They submit itThe signature is passed to the token or an intermediary contract, which records the allowance.
    4. Step 4They spendTokens move within the terms you signed — amount, spender and deadline — by a transaction you never sent.

    The gap between step one and step four can be minutes or weeks, which is why victims often cannot identify when the compromise happened.

    Six different things a wallet can be asked to do

    The last two are the pair worth internalising. A classic approval is a transaction you pay gas for and can see in your history. A permit is a signature: no gas, no history entry in your account activity, and the same practical outcome — a spender with an allowance.

    The request types are genuinely different. The danger is not in signing — it is in not knowing which of these you are signing.
    Request typeWhat it doesCan it move funds?
    Transaction (transfer)Submits a state change to the network — sending an asset from your address.Yes, immediately, once it confirms.
    Transaction (contract call)Submits a call to a contract function, which may do many things at once.Yes, depending on the function being called.
    Plain message signingSigns arbitrary text, most often to prove you control an address (a login or ownership check).No, by itself. It produces a signature, not a transaction.
    Typed-data signing (EIP-712)Signs a structured object your wallet can display field by field, defined by a domain and a type.Not at signing time. What the signature authorises depends entirely on who can use it and how.
    Token approval (transaction)Sets an allowance letting a spender address move up to some amount of one token from your address.Not at signing time; the spender can move up to the allowance afterwards.
    Permit-style authorisation (signature)A signed EIP-712 message that grants an allowance without you sending an approval transaction.Not at signing time; whoever holds the signature can submit it and then spend within its terms.

    EIP-712: readable structure, not a safety check

    EIP-712 defines a way to sign structured data rather than an opaque string. Each message declares a domain (name, version, chain ID and usually a verifying contract) and a typed structure, so a wallet can display named fields instead of a hash.

    That is a readability standard. It makes the content of a message presentable; it does not judge whether the content is in your interest. A perfectly well-formed EIP-712 message can grant an unlimited allowance to an address you have never seen.

    FACT: EIP-712 specifies how structured data is hashed and displayed for signing. EDITORIAL GUIDANCE: treat a nicely formatted request exactly as sceptically as an unreadable one — the formatting is the attacker's interface too.

    Permit mechanisms, and why they are not universal

    EIP-2612 adds a permit function to ERC-20 tokens, letting a holder approve a spender through a signature carrying an owner, a spender, a value, a nonce and a deadline. Other patterns exist: Permit2-style contracts extend signature-based allowances to tokens that never implemented EIP-2612, and some protocols define their own order or intent signatures.

    Support varies by token and by protocol. A token that does not implement permit cannot be spent through an EIP-2612 signature; the same wallet, on the same network, may therefore be exposed through one token and not another. Do not assume a mechanism is present or absent — read the request.

    What the fields in a permit-style request are actually deciding.
    FieldThe question it answersWhat to look at
    ownerWhose tokens are being committed?It should be your address, not a lookalike.
    spenderWho gains the ability to move them?An address or contract you can identify and expected to be involved.
    value / amountHow much can be moved?A specific amount tied to what you are doing, rather than a maximum-value number.
    deadline / expiryHow long does this stay usable?A short window. A distant deadline leaves the authorisation live for months.
    nonceCan it be replayed?Sequence control — useful context, not something you normally judge.
    domain / verifying contractWhich contract will accept this signature?Whether it matches the token or protocol you believe you are using.

    The “what exactly am I authorising?” framework

    1. Name the type. Is this a transaction, a plain message, or typed data? Wallets label this differently, but they do say.
    2. Name the beneficiary. Which address gains a capability — the spender, the operator, the recipient? If no address gains anything, the request is probably a login proof.
    3. Name the asset and the ceiling. Which token, and what is the maximum that can move under this authorisation?
    4. Name the duration. Does it expire, and when? An authorisation with no practical expiry is a standing one.
    5. Name the trigger. Does it take effect when I sign, when someone else submits it, or only if a further condition is met?
    6. Say it out loud in one sentence. If you cannot complete “this lets ___ move up to ___ of my ___ until ___”, you do not yet know what you are approving.

    Editorial guidance: an unfinished sentence is a reason to stop, not a reason to guess. Rejecting costs nothing; a legitimate request can be made again.

    How permit phishing is usually staged

    The delay is the reason victims often cannot identify the moment of compromise. This is also why 'nothing happened when I signed' is not evidence that nothing was granted.

    1. You reach a page through an advertisement, reply, airdrop notice or cloned domain.
    2. The page asks you to connect, which reveals which tokens your address holds.
    3. It presents a signature request framed as verification, eligibility, a claim or a login.
    4. The request is in fact a permit-style authorisation naming an attacker-controlled spender, often for the maximum value.
    5. Nothing appears to happen. There is no gas prompt and no transaction in your history.
    6. Later — minutes or weeks — the signature is submitted and the tokens are moved by a transaction you never sent.

    What genuinely reduces exposure

    • Treat signature requests as authorisations, not formalities, and read the beneficiary and the amount every time.
    • Prefer bounded amounts and short deadlines over maximum-value, open-ended approvals wherever the interface allows it.
    • Keep high-value holdings in a wallet that never connects to applications, so a signature prompt there is always wrong.
    • Review existing allowances periodically and revoke what you no longer use — noting that revoking affects future spending, not a transfer that already happened.
    • Take wallet or extension warnings seriously; a missing warning is not a clean bill of health.

    Not every signature is a threat

    Signing is a normal part of using a wallet. Proving address ownership to log in to a site, signing an off-chain order that you initiated and understand, or approving an exact amount for a swap you are performing are all ordinary actions.

    The distinction is not signature versus transaction. It is whether you initiated the interaction, can identify who gains what, and can state the limit and duration.

    Frequently Asked Questions

    I signed something and no funds moved. Am I fine?

    Not necessarily. Permit-style signatures grant an allowance that someone else submits later, so the absence of an immediate transfer tells you nothing. Review the allowances on the address and revoke anything you do not recognise.

    Does revoking an approval undo a transfer that already happened?

    No. Revoking removes the ability to spend in future. A transfer that has confirmed cannot be reversed by you, the token issuer or the network.

    Can every token be drained through a permit signature?

    No. Permit is a feature a token or an intermediary contract has to implement. Exposure depends on the specific token and the contracts your address has interacted with.

    Is a gas-free request safer because it costs nothing?

    No — the absence of a gas fee is often what identifies it as a signature rather than a transaction, which is exactly the category that can be used later.

    Sources

    Spotted something out of date? See our corrections policy and fact-checking policy.

    Continue reading

    Educational information only. Nothing here is financial, legal or tax advice.