Token permissions: connect, approve, sign and revoke

Four requests that should not be confused

A decentralized application can ask to connect to a wallet, request a signature, propose a token approval or request another transaction. Those words describe different actions. A connection commonly shares the selected public account and lets the site request later actions. An approval can authorize a spender to move a particular token under contract rules. A signature can also carry meaningful authority, depending on the message and protocol.

Read each request as a fresh decision. Do not infer that a trusted-looking homepage makes every later request appropriate. Likewise, a transaction without an immediate asset transfer may still change a permission. Before accepting, explain in ordinary language what is being authorized, on which network, for which account and for which counterparty. If you cannot explain it, there is no need to sign to find out.

Evidence: Token approvals · Disconnect vs revoke

MetaMask describes its own wallet and general token-approval concepts; other providers and token implementations can differ.

The token, spender and allowance form the permission

For the familiar fungible-token allowance model, the owner authorizes a spender to use a quantity of a specific token. The spender is an address, often a contract. The allowance is separate from the wallet's connection list. Record the token contract, network, spender and amount rather than writing only the application's brand. An unlimited allowance can expose a larger balance than the amount needed for a single intended operation.

An approval is not normally ownership transfer by itself. It creates authority that the spender can use according to the token and application rules. Depositing tokens into a farm or lending protocol can involve an approval followed by a separate interaction. Revoking the remaining allowance does not automatically withdraw a position already deposited into that protocol. Identify the actual operation instead of treating every approve button as a harmless login step.

Evidence: ERC-20 specification · BEP20 token-contract interface specification

Used only for the BEP20 token-contract interface and the methods/events named in the specification. It does not prove that a particular deployed contract conforms, is authentic, safe, issued by a named party, backed by reserves or equivalent to an asset on another network. The file contains historical Beacon Chain wording that is not treated as current migration guidance.

No gas fee does not mean no consequence

Some permission systems use signed messages. ERC-2612 is one specific token standard: a valid permit message can set an owner’s allowance for a spender when the contract accepts a later permit call. The signature alone does not write the allowance onchain, but it can be presented before its deadline; under the standard, a caller other than the owner may submit it. “No gas prompt” therefore does not mean “no authority.” This explanation applies to ERC-2612 implementations, not every EIP-712 signature or permit variant.

For an ERC-2612 request, compare the token/verifying contract and network context shown by the signing domain, then read owner, spender, value, nonce and deadline. The domain normally binds the message to a specific contract and chain context; wallets may display these fields differently or incompletely. Check the amount as the standard’s allowance value, not as a token transfer. If the contract, network, spender, amount, nonce or expiry cannot be explained, do not sign merely to inspect it.

A readable wallet summary can help but cannot replace checking what the exact message authorizes. Do not paste a signature, phrase, private key or authentication code into a site or support conversation. For non-ERC-2612 messages, identify the applicable protocol specification and fields; do not assume the same consequences or cancellation path.

Evidence: Signed approvals

Solve a fictional ERC-2612 permit request

Hypothetical fields, not a real wallet request: chain ID 56; verifying token contract [ABC_CONTRACT]; owner [ACCOUNT_A]; spender [SPENDER_X]; value 60 ABC; nonce 8; deadline [FICTIONAL_DEADLINE]. The bracketed labels are fictional, not addresses or a usable signature. The owner’s current allowance to X is 20 ABC and the balance is 250 ABC.

Read the value as the new allowance specified by this ERC-2612 permit, not as a transfer of 60 ABC. If the message is valid for that domain, nonce and deadline, and a permit call is later accepted by the token, the allowance for A → X becomes 60 ABC. Before such submission, the onchain allowance remains 20 ABC. A third party could submit a valid permit under the standard; the caller pays the transaction fee. The owner need not have sent that onchain transaction merely to create the signature.

The balance remains 250 ABC in this hypothetical because permit changes allowance, not token balance. Spender Y’s allowance is a separate record. A completed check would compare the exact network/token/owner/spender, verify the permit call’s successful receipt if submitted, then read allowance A → X again; a signature displayed or shared is not proof that the onchain state changed. No signature was created, submitted or tested for this exercise.

Evidence: Signed approvals · ERC-20 specification

Review before authorizing a swap or farm action

Start from the project's documented official address and contract information. A matching token ticker or a search result is insufficient. Determine whether your planned action really requires a spending permission. Compare the requested spender with the contract expected for that action. A proxy or router can add complexity; a verified source-code label alone does not demonstrate that its behavior, administration or upgrade rules are safe.

Decide whether the requested amount is proportionate to the operation. A smaller allowance can limit a particular permission's exposure, but it does not remove malicious-contract risk, harmful signatures, compromised keys or risk from assets already deposited. A farm's advertised yield is not compensation guaranteed to cover those risks. Avoid signing under urgency. Read the withdrawal and permission documentation before committing funds, rather than after a problem occurs.

Evidence: Token approvals · ERC-20 specification

MetaMask describes its own wallet and general token-approval concepts; other providers and token implementations can differ.

What revocation means in an allowance model

In the conventional ERC-20 allowance model, a permission is scoped to an owner, token contract and spender. Revocation describes a separate onchain state change for that specific permission; setting an allowance to zero means that spender has no remaining allowance in that record. It is not the same as disconnecting an app and does not itself transfer tokens.

A state change may require a network fee, and the method or product interface depends on the token and current wallet/protocol documentation. Other authorization schemes, including signed permits, can have different rules. This guide is conceptual and does not tell you how to create, send, cancel or confirm a revocation.

Changing one allowance says nothing about another spender, another network, assets already deposited in a protocol, or separate signature authority. It does not recover assets or repair exposed keys. A zero value in one allowance record is a narrow fact, not a finding that an account or application is safe.

Evidence: Disconnect vs revoke · ERC-20 specification · Signed approvals

Interpret a hypothetical allowance change

Fictional BSC example, chain ID 56: owner [ACCOUNT_A], token [ABC_CONTRACT], spender [SPENDER_X], allowance 100 ABC and token balance 250 ABC. In this hypothetical record, X’s allowance is later represented as 0 ABC. The bracketed names are fictional labels, not real addresses or observed chain data.

That value of 0 means only that the remaining allowance for this exact owner-token-spender record is zero in the stated hypothetical state. It does not mean 100 ABC or 250 ABC moved. The token balance remains 250 ABC in the example; no transfer is represented.

If spender Y has a separate allowance of 200 ABC, that other record remains 200 ABC. This example says nothing about a different network, a deposited position, an unsubmitted signed authorization or exposed keys. It illustrates only the meaning and scope of a value; no wallet or live chain state was examined.

Evidence: ERC-20 specification · BEP20 token-contract interface specification · Disconnect vs revoke · Signed approvals

Used only for the BEP20 token-contract interface and the methods/events named in the specification. It does not prove that a particular deployed contract conforms, is authentic, safe, issued by a named party, backed by reserves or equivalent to an asset on another network. The file contains historical Beacon Chain wording that is not treated as current migration guidance.

Disconnecting closes a session, not all authority

Disconnecting an app in the wallet controls its connection to the interface. It does not, by itself, erase token allowances already recorded onchain. Revoking one allowance changes that permission; it does not prove the whole account is safe. If someone has the private key, they can authorize further transactions regardless of the connection list. Different threats need different responses.

Use a written incident record: the site visited, public account, network, suspicious request, token and spender, transaction hashes and actions already completed. Keep secrets out of the record. If a wallet or browser displays a danger warning, stop and investigate through official channels. Do not disable the protection merely because a page claims to be educational or because no wallet button is visible. A redesign cannot certify that a domain's warning is resolved.

Evidence: Disconnect vs revoke · Wallet recovery models