A user installs Phantom on their browser and finds a streamlined interface for managing assets across Solana, Ethereum, Base, Polygon, Bitcoin, Sui, and other blockchains. Within minutes, they can connect to a lending protocol, liquidity pool, or token swap service. The connection process feels simple: approve the site, confirm in Phantom, and the Web3 interaction begins. What the interface does not always make explicit is that “approval” often grants far broader permissions than a single transaction. The wallet itself remains non-custodial—Phantom never holds private keys—but the user has just delegated specific transaction authorities to a smart contract, and those authorities can persist beyond the intended use case.

This distinction between wallet custody and contract permissions is central to DeFi security. A self-custodial wallet protects users from the wallet provider becoming insolvent, hacked, or censoring withdrawals. It does not prevent a poorly designed or malicious smart contract from draining an approved token balance, repeatedly charging transaction fees, or creating exposures that outlast a single transaction. Understanding what permissions are granted, why they exist, and how to revoke them is the difference between acceptable risk and preventable loss. Most users never examine the actual contract call or the scope of the approval, yet that is where the real exposure lives.

The anatomy of a DeFi wallet connection and what permissions actually mean

When a user clicks “Connect Wallet” on a decentralized application, Phantom displays a permission request that typically shows the site’s name and logo. The user can see which accounts will be connected, but the request rarely itemizes what the application can do with that connection. At the technical level, the application has announced itself to Phantom and requested access to specific accounts. Phantom’s role is to confirm that the user owns those accounts (by asking the user to confirm the connection) and then allow the application to submit transactions to the blockchain on the user’s behalf.

A distinction worth making immediately: a wallet connection is not a blanket permission to spend funds. Wallet connection establishes an identity relationship. The application can see the user’s public address and request that Phantom sign transactions. It cannot access private keys or sign transactions without the user’s explicit approval in Phantom for each action. That architecture is sound. The problem arises in what happens next, when the user approves a transaction that includes a token approval.

A token approval is a separate smart contract interaction that grants an application (or more precisely, a smart contract deployed by the application) permission to spend a specified amount of a token on behalf of the user. If a user wants to swap 100 USDC on a decentralized exchange, the exchange needs to be allowed to move that USDC from the user’s wallet to the exchange contract, where the swap logic can execute. To do this, the user must approve the exchange contract to spend up to a certain amount of USDC. In practice, applications often request approval for an extremely large amount—sometimes the theoretical maximum possible value, often written as 2^256 – 1 or “unlimited.”

This practice is common because it reduces friction: the user approves once, then can perform multiple swaps without re-approving for each transaction. The cost is persistence. Once approved, the application’s contract retains that permission indefinitely until the user explicitly revokes it. If the application is later compromised, the attacker can drain the approved balance without further interaction from the user. Phantom itself displays transaction previews and security features to identify suspicious activity, but approval permissions are evaluated differently from individual spend transactions. The wallet shows what is being approved; the user must decide whether the risk is acceptable.

Why unlimited approvals persist despite known risks

The technical reason unlimited approvals exist is efficiency. Ethereum and its compatible chains (Base, Polygon, and others) charge a transaction fee for every interaction with a smart contract. If a user must re-approve a token each time they swap, they pay the approval fee repeatedly, which adds up quickly. An approval for an extremely large amount (or “infinite” approval) means the user pays the fee once and can then perform unlimited swaps without additional approval transactions. This is mathematically wasteful for users who perform only one or two transactions, but economical for frequent traders.

Exchanges and lending protocols adopted this pattern because it improves user experience. Fewer approval steps mean fewer moments where a user might abandon the transaction. When Uniswap, Aave, or other major DeFi platforms adopted unlimited approvals as a default, smaller applications followed, and it became the standard practice. Users came to expect it. Any application requiring re-approval for each transaction would appear less competitive, even if it were safer.

The security consequence is that approval scope and transaction scope diverge. A user intending to swap $500 worth of USDC approves the contract to spend unlimited USDC. If the contract is compromised—through a smart contract exploit, a private key leak, or a protocol upgrade that changes behavior—the attacker’s exposure is not limited to $500. It is the entire USDC balance in the wallet. This is not Phantom’s fault; the wallet is doing exactly what the user requested. The risk is embedded in the contract interaction itself, and only the user can mitigate it by revoking approvals or using limited approval amounts.

The problem is compounded by the fact that most users do not check whether an approval is unlimited. Phantom’s transaction preview will show the approval amount, but a number like “115792089237316195423570985008687907853269984665640564039457584007913129639935” does not immediately register as “unlimited” to most people. The wallet could display this more clearly—showing “Unlimited” or “Type(uint256).max” rather than the raw number—but ultimately, the user must make an informed decision about whether to grant that permission. The application’s interests and the user’s security interests are misaligned.

Multi-chain exposure and per-chain permission management

Phantom supports connections across Solana, Ethereum, Base, Polygon, Bitcoin, Sui, HyperEVM, Robinhood Chain, and other blockchains. Each chain has its own token standards and approval mechanisms. An approval on Ethereum does not affect USDC on Polygon or Solana. A user connecting the same Phantom wallet to the same application on multiple chains may need to approve tokens on each chain separately. This is both good and bad: approvals are isolated by chain, which reduces systemic risk, but the user must revoke permissions on each chain if they want to fully sever the relationship.

This becomes a real problem when a user connects to an application on Ethereum, approves a token, performs a transaction, and then never uses that application again. The approval remains on the Ethereum chain indefinitely. If the user later uses a blockchain explorer or a specialized tool to check their approvals, they may find approvals for contracts they no longer recognize or contracts associated with applications they no longer trust. The wallet itself does not provide a built-in “approval revocation dashboard,” so the user must either manually check the contract on a blockchain explorer and revoke it there, or use a third-party tool designed to show and manage approvals.

The multi-chain nature of Phantom also creates a mental model problem. Users think of their Phantom wallet as a single entity—one recovery phrase, one interface—but the security boundaries are actually per chain and per contract. An approval granted to a contract on Polygon has no relationship to an approval on Solana, even though they protect the same underlying recovery phrase. If a user loses confidence in a particular contract on one chain, they cannot “disconnect” from it through Phantom; they must revoke the approval through a blockchain interaction, which requires paying a network fee on that chain. This friction is intentional (every on-chain action should cost something to discourage spam), but it means users often leave dangerous approvals in place simply because revoking them feels annoying or expensive.

Smart contract exploits and the difference between wallet security and application security

Phantom provides transaction previews and alerts for suspicious activity, which can catch some classes of attack. If a user approves a contract that immediately attempts to drain their wallet, the alert may flag it. However, this defense assumes the contract’s intent is immediately apparent and that the attack happens during the approval transaction itself. Many exploits are subtler. A contract might be legitimate for months, perform its function correctly, and then be upgraded by the developers in ways that expose user approvals to new risks. An attacker might find a flaw in the contract logic that allows them to call functions in unexpected ways. A seemingly trusted team might compromise a private key and use it to drain approved balances.

The distinction between wallet security and application security is critical. Phantom’s security is about protecting the user’s private keys and ensuring that every transaction must be explicitly approved by the user. The wallet succeeds at this. Application security is about whether the smart contracts being called are free of exploits and whether the teams operating them can be trusted. This is entirely outside Phantom’s control. A user can have perfect wallet security—strong recovery phrase backup, no phishing, clean device—and still lose all their approved assets because they connected to a vulnerable or malicious smart contract.

This is why security audits, track records, and governance models of DeFi protocols matter. Aave, Curve, and Uniswap have survived years of use, thousands of transactions, and external audits. Newer protocols, especially those offering unusual yield promises or unusual features, have not. Users should treat approval decisions as irreversible for practical purposes and should never approve a contract they have not had time to evaluate or do not fully understand. The official Phantom security guidance emphasizes verifying the application before approving, which is sound advice, but it also acknowledges that users must perform this evaluation themselves—the wallet cannot do it for them.

Practical approval management and revocation strategies

Users who have connected to multiple DeFi applications should periodically audit their approvals. On Ethereum and Polygon, tools like Etherscan and PolygonScan allow users to search their address and view approved contracts. Specialized tools like Revoke.cash (or similar platforms) show all approvals for a given address and allow users to revoke them in bulk or individually. On Solana, the approval mechanism is different—many applications do not use persistent approval, instead requesting authorization for single transactions—which reduces the accumulation problem but requires understanding chain-specific patterns.

Revocation is straightforward: the user connects Phantom to the revocation tool, approves a transaction that sets the spender’s approved amount to zero, and pays a network fee (paid to blockchain validators, not Phantom). The fee is unavoidable and often ranges from a few dollars to tens of dollars depending on network congestion. This cost discourages users from revoking every approval, so the practical strategy is to revoke only approvals for applications the user no longer trusts or no longer uses. Users should revoke immediately if they discover that an application they approved has been compromised or is in active development, where unexpected contract upgrades might occur.

A more conservative approach is to use limited approvals instead of unlimited ones. When connecting to a new application, a user can request approval for a specific amount (e.g., $1,000 instead of unlimited) and choose to re-approve if they need to perform larger transactions. This requires additional approval transactions, which costs fees, but limits exposure if the contract is later compromised. The application must support this workflow, and it is less common because applications optimize for user convenience rather than user caution. A user can also use separate wallets for different risk levels—a “hot” wallet for frequent trading with smaller balances and limited approvals, and a “cold” wallet for long-term holding with no approvals.

Phantom’s role in this process is to ensure that approvals are explicit and reversible. The wallet displays what is being approved and requires user confirmation. It does not revoke approvals automatically, because the user might legitimately want to keep the approval active. The wallet also does not alert users to old approvals or maintain a dashboard of current approvals, because that would require Phantom to monitor every user’s on-chain activity continuously. Users must take responsibility for tracking their own approvals and revoking them when appropriate. This is a limitation of decentralized wallet design—convenience requires centralized monitoring, but centralized monitoring requires Phantom to know which contracts the user has approved, which is a privacy trade-off.

The hidden cost: NFTs, multisigs, and less obvious permission vectors

Token approvals are the most visible permission type, but Phantom users grant other permissions when connecting to decentralized applications. NFT applications request permission to move NFTs. Some applications use multi-signature contracts, where the user’s approval is one of multiple required signatures for a transaction. Staking applications request permission to lock tokens for specified periods. Each of these mechanisms has different risk profiles and different revocation requirements.

NFT permissions operate differently from token approvals, but the same principle applies: a user might approve an NFT marketplace to move any NFT in their collection, and if the marketplace is compromised or the contract has a flaw, the entire collection could be at risk. Users viewing NFTs in Phantom can see them, and Phantom will prompt the user when an application requests NFT transfer permissions. However, unlike token approvals, NFT permission revocation is less standardized and less commonly available. Some applications allow revocation; others do not. A user who approved a malicious NFT contract may find themselves unable to revoke the permission without directly interacting with the blockchain—a process that many users do not know how to perform.

Multisig wallets add another layer. If a user is part of a multisig arrangement—where multiple private keys are required to approve transactions—then connecting to a DeFi application requires signatures from all parties. This can be more secure (no single compromised key can drain the wallet) but also more cumbersome (every transaction requires coordination). Phantom supports connecting to multisig wallets on certain chains, but users must understand that their approvals are binding on behalf of the entire multisig, not just their individual key. If one signer in a multisig approves a malicious contract, the other signers are implicated.

When transaction preview and security alerts are insufficient

Phantom’s transaction preview feature shows the user what will happen if they approve a transaction. For a swap on Uniswap, it displays the input amount, output amount, slippage, and fee. For an approval, it shows the contract address and the amount being approved. This information is valuable and significantly better than a wallet that hides transaction details, but it assumes the user can evaluate what they see. If a user does not recognize a contract address or does not understand what an approval implies, the preview does not help.

Phantom also flags suspicious activity. If a contract attempts to do something unexpected or if the transaction looks like a common attack pattern, Phantom may display a warning. However, these alerts are necessarily conservative: they must avoid false positives, or users will ignore them. A novel attack that does not match a known pattern will not trigger an alert. A contract that is designed to do something unusual but legitimate might trigger a false positive. The wallet cannot distinguish between an intentional and unusual use case and an actual attack.

The most effective protection is user judgment combined with a strong threat model. A user should ask: Do I recognize this application? Have I read about it from trusted sources? Is the contract address consistent with what I expect? Am I about to approve something larger than I plan to spend? Do I trust the developers? Is there a governance structure that could change the contract’s behavior? These questions cannot be automated. Phantom can display information; the user must evaluate it. This responsibility falls entirely on the user, which is the intended design of a self-custodial wallet, but it also means that user education is more important than wallet features alone.

Recovery and post-breach procedures

If a user suspects that a Phantom wallet has been compromised—for example, if unauthorized transactions appear in the wallet’s history—the first step is to move remaining assets to a new wallet before doing anything else. A new Phantom wallet or a hardware wallet with a fresh recovery phrase can receive the remaining assets from the compromised wallet. Once the funds are secure, the user can address the approvals that were granted from the compromised wallet.

The compromised wallet’s approvals do not automatically transfer to the new wallet, because the new wallet has a different private key and address. Applications approved the original address to spend tokens, not the user identity. If an attacker has the recovery phrase of the compromised wallet, they can still access approvals on that wallet, so the user should consider all approvals on that wallet to be exposed. Revoking them is optional from a security perspective (since the attacker can spend approved tokens whether or not the user revokes them), but doing so may prevent additional attacks or may be useful for audit purposes.

The user should also trace how the compromise occurred. Did a phishing site steal the recovery phrase? Did a malicious browser extension capture the seed phrase during setup? Did an application or a hardware flaw leak the private key? Understanding the vector is important because it informs whether the new wallet is at risk from the same attack. If a phishing site was involved, the user needs to change behavior on that device. If a browser extension was involved, that extension should be uninstalled. If a hardware flaw was involved, the device might need to be replaced. Phantom itself cannot protect against a compromised device or a stolen recovery phrase, which is why device security and backup procedures are the true foundation of wallet security.