Approve, Permit and WalletConnect: How Permissions Can Drain Your Tokens

Approve, Permit and WalletConnect are common DeFi mechanisms that can give a contract permission to interact with your assets. Crypto security usually starts with protecting your seed phrase: keep it offline, never enter it on random websites, and never share it with anyone. But that alone is not enough if you approve a permission or signature without checking exactly what it authorizes.

Approve, Permit, Permit2, WalletConnect and EIP-7702 delegations all work differently, but the critical moment is often the same: you see a familiar Confirm or Sign button and approve the request without understanding what it actually does. Your private keys can remain fully protected while the permission you just granted is enough to move your tokens.

This guide focuses on what matters before you confirm a request: how approve and Permit work, why Unlimited approval can be risky, why Disconnect is not the same as Revoke, what WalletConnect actually does, and what changed with EIP-7702. We will also cover how to review active permissions and what to do after signing something suspicious.

Approve, Permit and WalletConnect: where the risk comes from

Simply opening a website does not give a smart contract permission to spend your ERC-20 tokens. In most cases, it needs a previously granted allowance — permission for a specific address or contract to spend up to a certain amount through transferFrom.

Ordinary swaps, staking and lending depend on this mechanism. The first time you use a new token, a dApp will often ask for an approve transaction before it performs the actual swap. Before confirming it, check who is receiving the permission, how much they can spend, and how long the permission lasts.

According to Scam Sniffer, wallet drainers stole about $494 million from 332,000 addresses in 2024, with malicious Permit signatures accounting for a meaningful share of losses in major incidents. Total losses from this type of attack fell substantially in 2025, but the attack vector did not disappear: convincing a wallet owner to sign the right message is often easier than stealing the private key itself.

This distinction matters even if you use a hardware wallet. The device isolates your private keys and signs requests internally, but it does not decide whether a contract is trustworthy or whether you truly intended to grant those exact permissions. If you confirm a malicious request on the device, the wallet can sign it without ever exposing the private key.

What a typical permission-based attack looks like

A typical attack looks completely ordinary. You land on a fake airdrop, mint page, or a copy of a familiar DeFi service, connect your wallet, and receive a request that seems like the natural next step: Claim, Continue, Verify, or Sign.

Behind that button could be an approve for an attacker-controlled address, a Permit for a large amount, or another type of authorization. The risk appears when you approve the specific request: once the signature is valid, the permission may be used without asking you again.

The signatures you may see in your wallet

The Sign button can refer to very different actions: logging in to a website, signing a structured Permit, or approving a raw hash that the wallet barely explains. Knowing the most common signature formats helps you understand what you are being asked to approve.

eth_sign: a signature without readable context

eth_sign signs a raw 32-byte value that a typical user cannot meaningfully verify in a normal wallet interface. Because it provides so little readable context, the method is considered risky for everyday dApp use, and modern wallets often restrict it or hide it behind additional settings.

If a website asks you to enable eth_sign separately just to continue, it is better not to approve the request. Modern DeFi services usually support signature formats that let the wallet show more useful information about what you are authorizing.

personal_sign: commonly used for login

personal_sign is commonly used for authentication or to prove ownership of an address. It is not a standard Ethereum transaction, but you should still read the message carefully: a service may treat that signed message as authorization for a specific action within its own protocol.

EIP-712: structured signatures

EIP-712 allows a wallet to display structured fields instead of an unreadable block of hex data — for example, the spender, amount, deadline, network, and contract. Permit and many Permit2 flows use this format.

A structured format makes the request easier to inspect, but its safety still depends on the values inside it. If the spender points to an attacker-controlled address and value allows an excessive amount to be spent, the readable format only helps if you actually review those fields.

Approve: the standard ERC-20 permission

The approve(spender, amount) function records how much the specified spender is allowed to spend from your balance. The approve call itself does not move your tokens; funds move only when the approved spender later calls transferFrom.

Why Unlimited approval increases the risk

To avoid asking for approve before every transaction, dApps often request a very large or effectively unlimited allowance. That reduces the number of approvals required for future swaps, but it also leaves the contract with broad spending authority that can remain active for years.

An old allowance does not disappear just because you stopped using the service. It remains recorded in the token contract until it is changed or revoked. If the contract or related infrastructure is compromised later, an attacker may be able to use the permission you already granted without needing another signature from you.

For NFTs, setApprovalForAll serves a similar purpose by allowing an operator to manage every NFT you own from a particular collection. Fake mint and claim sites can present this request as a routine step even though the permission is much broader than a single NFT transfer.

Permit: granting permission with a signature

A standard approve requires an on-chain transaction and gas. EIP-2612 Permit works differently: you sign a message off-chain, and a service, relayer, or another party later submits that signature to the token contract.

The message includes fields such as owner, spender, value, deadline, and nonce. After verifying the signature, the contract creates an allowance without a separate approve transaction, which makes the process faster and avoids gas for the user at the signing stage. That can make a Permit feel like an ordinary message even though it may authorize real token spending.

Signing a Permit may leave no transaction in your wallet history at that moment. A valid signature can be submitted later, as long as the deadline has not passed and the relevant nonce has not already been used.

In March 2026, researchers analyzed an incident in which roughly $1.76 million in USDC was drained after a malicious Permit signature. According to GoPlus, the user’s device had been compromised, allowing the attackers to replace the request and obtain a valid signature; the incident did not involve a vulnerability in Permit itself.

If no new allowance appears in a block explorer, that does not rule out the risk. Until the Permit signature is submitted on-chain, a normal approvals list may not show it at all.

What the domain separator does

The EIP-712 domain separator binds a Permit to a specific network and contract, reducing the chance that the same signature can simply be replayed in a different context. It does not verify whether you chose the correct spender, however: a signature intentionally or accidentally granted to a malicious address can still be perfectly valid.

Permit2: one permission system for many tokens

Not every ERC-20 token supports EIP-2612, so Uniswap created Permit2 as a separate, universal permission layer. You first grant the Permit2 contract a base on-chain approve, then use signatures to give individual dApps more specific permissions.

When reviewing Permit2, check two separate layers: the token’s base approve for the Permit2 contract and the permissions individual applications received through Permit2. Revoking one application-level permission does not necessarily remove the underlying allowance.

Structured Permit2 signatures can contain many technical fields, which makes it easy to approve them mechanically without checking who receives the permission or how broad it is. Phishing flows often rely on exactly that behavior while presenting a familiar-looking DeFi interface.

WalletConnect: connecting without direct access to your tokens

WalletConnect is sometimes mistaken for a separate permission to access your assets. Its role is different: the protocol connects your wallet to a dApp and carries requests between them. Connecting through a QR code or deep link does not, by itself, create a token allowance.

Once the session is established, the dApp can send an approve, Permit, transaction, or message-signing request. Your wallet displays each request separately, so the important question is what the specific action you are about to sign actually authorizes.

When an incident is described as “stolen through WalletConnect,” the underlying cause is often a malicious request delivered through an open session and approved by the user, rather than a compromise of WalletConnect itself.

Why old sessions should be closed

Closing a browser tab does not necessarily end a WalletConnect session, so an old connection may remain active and continue receiving requests from the dApp. It is a good idea to close old or unfamiliar sessions periodically, even though those sessions do not create on-chain permissions by themselves.

Disconnect ends the WalletConnect session with the dApp, while Revoke changes or cancels an on-chain allowance. If a contract previously received Unlimited approval, disconnecting the WalletConnect session does not affect that permission.

What remains after Disconnect

After Disconnect, the dApp disappears from your active sessions, but a previously granted approve remains valid because the allowance is stored on-chain in the token contract. Closing the tab, clearing cookies, or disconnecting the site does not change that record.

Revoking an allowance does not necessarily end the WalletConnect session either. If you no longer use a service, review both the active connection and any on-chain approvals separately.

EIP-7702: a new risk after Pectra

EIP-7702 went live on Ethereum with the Pectra upgrade on May 7, 2025. It allows an EOA to delegate execution logic to another contract while keeping the same address, enabling features such as batching, third-party gas payment, spending limits, and other smart-account functionality.

Those capabilities also increase the amount of authority a delegated contract can receive. If you authorize a contract with malicious or substituted logic, a single delegation may allow a batch of actions that would previously have required several separate confirmations.

Wallet drainers began using EIP-7702 soon after Pectra. Reports from 2025 describe major losses involving malicious batch signatures, while researchers also documented sweeper contracts using 7702 on addresses whose keys had already been compromised.

The risk depends on the scenario. If an attacker already has the private key, EIP-7702 can help automate draining funds from the compromised address. In another scenario, the key remains with the owner, but the user is tricked into signing a dangerous delegation. In the first case, funds should be moved to a new wallet with fresh keys; in the second, revoke the unwanted delegation and check for any other signs of compromise.

An unfamiliar smart-account or EIP-7702 delegation deserves investigation. Check which contract received the delegation and when it happened. An unknown delegation does not automatically mean your seed phrase has been exposed, but it should not be ignored.

How to review and revoke permissions

There is no single place to review Approve, Permit and WalletConnect. On-chain approvals are checked through permission-management tools or a block explorer, while WalletConnect sessions are managed directly in your wallet. For ERC-20 tokens and NFTs, a service such as revoke.cash can show active approvals and the contracts that hold them.

• ERC-20 approve. Review Unlimited and unusually large allowances, especially those granted to old or unused contracts.
• NFT approvals. Check setApprovalForAll if you have used mint sites, marketplaces, or other NFT dApps.
• Permit2. Review both the base approve granted to Permit2 and the individual permissions issued to applications through it.
• WalletConnect. Close old and unnecessary sessions separately from your review of on-chain permissions.

Revoking an on-chain permission is a separate transaction and requires gas, so cancelling every approval immediately after use is not always practical. A better approach is to review your permissions periodically and remove those you no longer need, especially after experimenting with new DeFi services, mints, or airdrops.

Permit is different: an off-chain signed message will not appear among your on-chain approvals until it is used. If you have reason to believe an attacker obtained that signature, do not wait for a new record to appear in an explorer before protecting your assets.

There is no need to audit permissions every day, but after actively testing new DeFi protocols, it is worth checking which contracts still have authority over your assets. This is especially useful before sending a significant amount of a token to an address that has granted approvals in the past.

What to check before signing

Before you press Confirm, check the fields that determine how much authority the request actually grants.

• Check the domain. Open DeFi services from bookmarks or official sources instead of relying on ads or random links.
• Verify the spender and contract. If an address is unfamiliar, compare it with the service’s official documentation or check it in a block explorer.
• Check the amount and deadline. An Unlimited amount or an unusually long validity period for a one-time action deserves extra scrutiny.
• Do not sign unreadable data. If your wallet shows only raw hex with no understandable description of the action, you cannot meaningfully verify what the signature authorizes.
• Keep your main funds separate from experiments. Use a separate wallet with a limited balance for new dApps, mints, and airdrops.
• Verify the hardware wallet screen. Before signing, rely on the information shown by the device itself and make sure it matches the action you intended to perform on the website.

What to do if you already signed a suspicious request

If you just approved a suspicious approve, Permit, or EIP-7702 delegation and you are not sure what it authorized, assume the permission may already be usable. Protect your assets first, then investigate the details.

1. Move valuable assets to a safe address. This is especially important if you suspect an off-chain Permit signature may already be in an attacker’s hands.
2. Revoke suspicious on-chain approvals. Check ERC-20 approve, NFT setApprovalForAll, and Permit2 permissions.
3. Review EIP-7702 and smart-account delegations. Revoke any unfamiliar delegation. If you also see signs that the private key itself was exposed, move the funds to a new wallet with fresh keys.
4. End WalletConnect sessions and stop interacting with the suspicious site.

Once the funds are protected, review the transaction history, contract addresses, and signature data to determine exactly what permission was granted and whether any other active authorizations remain.

Conclusion

Approve, Permit and WalletConnect, along with Permit2 and EIP-7702, serve different purposes. Approve creates a token allowance, Permit lets you grant that permission with an off-chain signature, Permit2 centralizes permission management, WalletConnect carries requests between a dApp and your wallet, and EIP-7702 lets an EOA delegate smart-contract logic.

Before signing, verify the spender, amount, deadline, and contract even when the website is familiar and the request looks routine. Keep your main funds away from experimental dApps, and periodically review old approvals so you can revoke permissions you no longer need.

A hardware wallet protects your private keys, but you still need to verify the request before pressing Confirm. Secure key storage does not replace checking exactly what authority you are giving to a contract.