24.05.2026
Crypto Payments for Marketplaces: Orders, Reconciliation, Payouts
Read article
Connecting a wallet to a Web3 application does not usually give that application unrestricted access to every asset. The more important action often comes one step later, when the user approves a token for a smart contract to spend.
That approval allows a decentralized exchange to swap tokens, a lending protocol to deposit collateral, or a marketplace to transfer an asset. It is a normal part of using many dApps. It can also remain active long after the user closes the website.
The result is an awkward security gap: a wallet may look disconnected while an old contract still has permission to move a particular token. If the contract, its upgrade mechanism, or the user’s signed authorization is malicious, that allowance can put funds at risk.
This guide explains what token approvals are, how they differ from wallet connections and signatures, how to inspect them, and when to revoke them.
On EVM networks such as Ethereum, many fungible tokens follow the ERC-20 standard. The token contract keeps track of balances, but it can also keep an allowance: permission for another address or smart contract, called the spender, to transfer up to a specified amount on behalf of the token owner.
Two ideas matter:
Suppose a wallet holds 1,000 units of a token. A decentralized exchange router cannot simply take 100 tokens for a swap. The user first authorizes that router to spend the token. The router can then call the token contract to transfer the approved amount during the swap.
The approval belongs to a specific combination:
Approving one token does not automatically approve every token in the wallet. An approval on Ethereum also does not create the same permission on another network. This specificity is useful, but it makes permissions easy to forget when users interact with many tokens, dApps, and networks.
For background on the code performing these actions, see the explanation of how smart contracts work.
Approvals exist because smart contracts need a controlled way to perform an action the user requested without receiving the user’s private key.
A DEX may need permission to move the input token into a swap. A lending protocol may need to transfer tokens into a pool. A subscription or automation contract may need a defined spending allowance. The contract receives permission over the token, not ownership of the wallet’s seed phrase.
That distinction is important. A standard token approval does not reveal the seed phrase or private key. It does, however, authorize the spender to transfer a particular token under the rules of the allowance.
The permission may be used immediately and only once, or it may remain available for future interactions. The risk depends on:
This is why wallet security is broader than protecting recovery words. The guide to seed phrases and private keys explains access to the wallet itself; token approvals govern what authorized contracts may do after the wallet is already in use.
A limited approval authorizes a defined amount. If a swap needs 100 tokens, the user may approve exactly 100. Once the contract spends them, little or no allowance remains.
An unlimited approval gives the spender a very large allowance, often the maximum value the token contract can represent. Interfaces use this approach to avoid asking for a new approval before every future transaction. It saves time and gas, particularly for frequently used protocols.
Unlimited does not mean that the contract immediately receives the entire wallet. It means the contract can transfer the approved token up to the available balance and allowance when the relevant function is used.
The trade-off is straightforward:
There is no rule that every unlimited approval is malicious. Many established protocols use them. The problem is that the potential impact becomes larger if the spender is compromised, misconfigured, upgraded maliciously, or impersonated by a phishing site.
Wallet interfaces often show a list of connected sites. Disconnecting a site removes its ability to request information or new actions through that active wallet connection. It is useful, but it does not normally change allowances stored by token contracts on the blockchain.
Think of the difference this way:
Closing the channel does not erase a permission that was already recorded. Deleting browser history, removing a site from MetaMask, switching devices, or uninstalling a wallet extension also does not automatically revoke on-chain allowances.
To remove an ERC-20 allowance, the wallet usually needs to submit a new blockchain transaction that sets the spender’s allowance to zero or another lower amount. That transaction requires a network fee.
Users can review approvals through a wallet’s built-in security interface, a blockchain explorer’s approval checker, or a reputable permission-management service.
Before connecting the wallet, verify the domain independently. Approval dashboards are themselves common phishing targets because visitors arrive with a security concern and expect to sign or submit transactions.
For each permission, check:
The spender name shown by an interface is a convenience label, not final proof. If a permission looks unfamiliar, open the spender address in a trusted explorer and inspect whether it is verified, what transactions it performs, and which protocol links to it.
Knowing how to read the underlying transaction is useful here. A blockchain explorer can show the contract, method, address, status, and token activity.
The exact interface varies, but the underlying process is similar:
Revoking is itself an on-chain transaction. The wallet needs enough native network currency to pay gas, such as ETH on Ethereum or the corresponding native asset on another EVM network.
The transaction should modify an existing allowance. Be cautious if the wallet prompt contains an unexpected token transfer, contract deployment, asset sale, or unrelated interaction.
After confirmation, verify that the allowance is zero or reduced to the intended amount. Do not rely only on a success message from the website.
Revoking every approval after every transaction creates extra fees and friction. Leaving every approval active forever creates unnecessary exposure. A risk-based review is more practical.
Consider revoking when:
A frequently used, well-understood protocol may keep a limited allowance if that fits the user’s risk tolerance. High-value wallets should generally keep fewer standing permissions than small experimental wallets.
Users who regularly make a crypto swap through DEX infrastructure will encounter approvals more often than users who only receive and send assets. That is one reason to separate long-term holdings from an active Web3 wallet.
Not every spending authorization begins with a visible approve transaction.
Some tokens support a mechanism commonly called Permit. Instead of first sending an on-chain approval transaction, the user signs a structured message. Another party can submit that signature to the blockchain, where it creates the allowance if the signature is valid and has not expired or been used.
This can improve UX and reduce the number of transactions. It also means “I only signed a message” is not a sufficient safety check. A signature may grant spending authority even when the user did not pay gas at the moment of signing.
Permit2 is a more general permission system used by some applications. A user may first approve the Permit2 contract for a token and then sign more specific permissions for individual applications. This separates the token-level approval from later signed authorizations, but introduces another layer users need to understand.
When a wallet asks for a signature, inspect:
Reject blind signatures and unreadable authorization requests unless you fully understand the hardware, application, and transaction flow.
If you approved an unknown contract but funds have not moved, act before investigating at leisure.
First, stop interacting with the suspicious site. Open a trusted approval checker through a clean browser session or known bookmark, then revoke the relevant permission on every network where it may exist.
Next, inspect recent transactions and signatures. If the wallet holds material funds and you suspect broader compromise, move remaining assets to a new wallet created on a clean device. Revoking one token allowance does not repair a leaked seed phrase, malicious extension, or compromised signing device.
A practical response is:
Changing the wallet password is not enough if the seed phrase or private key was exposed. It only changes local access to that wallet application.
Be skeptical of “recovery services” that request a seed phrase, upfront payment, or remote access. The same urgency that led to the first mistake can make a second scam more convincing.
Web3 wallets expose several actions that look similar but have different consequences.
A connected site can see the public wallet address and request signatures or transactions. Disconnecting it closes that communication path, but does not remove on-chain token allowances.
A normal transaction signature authorizes a specific blockchain transaction. The wallet should display the destination, network, value, gas, and contract interaction.
A message signature may prove wallet ownership, sign in to a service, place an order, or authorize a Permit. Some messages have no financial effect; others can be used to create powerful permissions.
NFT standards have their own approval models. An approval may cover one token or authorize an operator to manage all assets in a collection. These permissions need a separate review from ERC-20 allowances.
Adding a network or importing a token into a wallet changes what the interface displays. It does not by itself authorize spending. A fake token can still be used as bait for malicious links, so unexpected assets should not be treated as free money.
The broader review of MetaMask’s features and risks helps place these permissions in context.
Approval hygiene works best when it is part of a wallet architecture, not an occasional panic after a suspicious prompt.
Use one wallet for active dApp interactions and another for reserves. Keep only the amount needed for current activity in the Web3 wallet. Review unlimited approvals periodically, especially after trying a new protocol.
Before approving anything:
These habits complement protection against other wallet attacks, including fake addresses inserted into transaction history.
A company may use Web3 wallets for swaps, treasury management, liquidity operations, contractor payouts, or protocol interactions. Those wallets should not be treated like personal browser wallets.
Business controls can include:
The company should also separate Web3 activity from customer payment processing. A wallet that signs experimental DeFi permissions should not be the only destination for business revenue or reserves.
CryptumPay can handle customer-facing crypto invoices, payment status, transaction history, and withdrawals without requiring employees to expose an operational Web3 wallet to every customer payment. The company can then transfer settled funds according to its own treasury policy.
This separation supports the broader security controls businesses need around crypto payments: wallet permissions, payment verification, AML screening, access control, and treasury authorization solve different parts of the risk.
Before approving or revoking a permission, confirm:
Token approvals are not inherently dangerous. They are a core mechanism that lets smart contracts work with user-owned tokens. The risk appears when permissions are broader than necessary, remain active longer than expected, or are granted through a malicious interface.
The safest approach is not to fear every approval. It is to understand what is being authorized, limit standing access, and revoke permissions that no longer have a clear purpose.
No. Disconnecting a site removes the active wallet connection, but on-chain token allowances normally remain until they are changed through a blockchain transaction.
Usually yes. Updating an ERC-20 allowance is an on-chain action, so the wallet needs the network’s native asset to pay the transaction fee.
A standard token approval does not reveal the seed phrase. It can authorize a spender to transfer a particular token. If the seed phrase was entered into a website or shared, assume the whole wallet is compromised.
No. Revoking can prevent future use of the allowance, but it cannot reverse transfers that have already been confirmed.
Not automatically. Review who the spender is, whether you still use the protocol, the value exposed, and your risk tolerance. Old, unknown, or unnecessary unlimited approvals are strong candidates for removal.
Create an account and connect the checkout yourself, or talk to sales and we will plan the integration with you.
