Review the spender and allowance, not only the website’s name.
A separate permission
The ERC-20 interface includes allowances that let a designated spender transfer tokens up to an authorised amount using the relevant function. This differs from a website merely learning a connected wallet’s public address. The token standard describes the mechanism, but applications can present permissions in different ways. Read the actual wallet request rather than treating every prompt as a harmless login.
An allowance example
Imagine approving a fictional application to spend 100 units of one token. That authorisation is about a specific token contract and spender, not a universal statement about every asset in the wallet. An unlimited allowance creates a different exposure from a tightly bounded amount. The example is conceptual; actual behaviour depends on the token and the mechanism the application uses.
Disconnecting is not revoking
Removing a site from a wallet’s connected-sites list normally changes the browser connection, not an existing on-chain allowance. Revocation requires the appropriate state change and may incur a network fee. Signed permission mechanisms can have separate rules, so a simple approvals screen may not describe every outstanding authorisation. Use trusted documentation and avoid unfamiliar “revoke” links sent in private messages.
A permission review habit
Confirm the network, token, spender, amount and purpose before approving. After using an application, review permissions you no longer need through a trusted interface. Never share keys with someone offering to clean up approvals. If the wallet preview is unclear, stop and investigate. The useful distinction is between viewing an address, signing a message and granting authority to move assets; these actions do not carry the same consequences.
Sources & further reading
Sources checked 7 October 2026. Source-linked explanatory content; not personalised investment advice. Found an error? Request a correction.
