On this page
- Identify the permission before reading the amount
- Wallet connection is not the same permission
- Follow the balance and allowance separately
- A spending cap is not a safety guarantee
- Signed approvals need their own checks
- Disconnecting and revoking solve different problems
- Frequently asked questions
- Sources and scope
A token approval can give another address permission to move a specified amount of a particular token from your account. In the ERC-20 model explained here, that permission is an allowance: an amount a named spender is still authorized to use. Setting the allowance is different from transferring the tokens.
Connecting a wallet, signing a message, approving a spending cap and sending tokens are also different actions. A button’s label is not enough to tell you which authority a request would grant. Read the token, network, spender, amount and the meaning of the request together.
This guide concerns ERC-20 token allowances and the named ERC-2612 signed-approval extension. It is not a rule for every blockchain, native ETH or SOL, NFTs, or every token implementation.
Identify the permission before reading the amount
An ERC-20 allowance belongs to a relationship between an owner, a spender and a token contract on a particular network. The owner holds the tokens. The spender is the address authorized to use an amount of those tokens. The token contract records the allowance.
The spender may be a contract used by an application. A familiar website name does not replace the contract identity: the site, the spender and the token are separate things to identify.
The ERC-20 standard distinguishes three relevant operations. An approve operation sets a spender’s allowance; calling it again sets a replacement amount rather than simply adding the new number. A transfer moves tokens from the caller’s account. A transferFrom moves tokens from another account under the applicable authorization. The allowance records remaining authority, not the amount already transferred.
Wallet connection is not the same permission
Basic wallet connection lets an application identify the connected account and request interactions. It does not, by itself, create an ERC-20 spending allowance. A separate request can still ask you to grant one.
A signature needs its own interpretation. A message may serve a login purpose, but a signed message can also authorize a consequential action. Some interfaces combine requests or offer more advanced account permissions. Do not assume that every screen containing “connect” or “sign” describes the same limited operation.
| Action or request | What to identify | What not to assume |
|---|---|---|
| Basic wallet connection | The account and site receiving connection permission | That connection alone sets a token allowance—or that every bundled request is only a connection |
| Message signature | The message’s purpose and the authority its data can carry | That no immediate gas charge means no financial consequences |
| ERC-20 approval | The network, token contract, owner, spender and allowance amount | That the approved amount has already been transferred or reserved |
| Token transfer | The token, sender, recipient, amount and completed transaction state | That a prior approval proves this transfer happened |
| Allowance revocation | The particular allowance being changed and whether that change completed | That it undoes earlier transfers or cancels every other authorization |
An approval does not disclose your private key. But retaining your private key does not make every authorization safe: a spender can use the permission you actually grant. The relevant question is what that permission allows, not just whether you still control the wallet.
Follow the balance and allowance separately
Suppose one fictional account holds 80 units of a fictional ERC-20-like token. It has initially authorized a particular spender to use zero units. The following rows are sequential events involving that one token, owner and spender on one network.
For this example, a successful spender transfer reduces both the owner’s balance and the finite remaining allowance by the quantity transferred. We exclude fees, rebasing and other balance changes except those shown. Every indicated state change has completed, with no pending or competing transactions. These are declared teaching assumptions, not an audit of an actual token.
| Sequential fictional event | Owner’s token balance | Spender’s remaining allowance | What changed |
|---|---|---|---|
| Initial state | 80 | 0 | No allowance for this spender |
| Approve 100 units | 80 | 100 | Permission changes; no tokens move |
| Spender transfers 30 units | 50 | 70 | Balance: 80 − 30; allowance: 100 − 30 |
| Disconnect the site only | 50 | 70 | The recorded token allowance is unchanged |
| Receive 20 more units | 70 | 70 | Balance rises by 20; no new approval is created |
| Completed change of allowance to zero | 70 | 0 | This spender’s allowance ends; earlier transfers are not reversed |
Approving 100 does not create the 20 tokens missing from the initial balance, send 100 tokens or lock them aside. It sets an allowance larger than the current balance. After the spender transfers 30, the two quantities are different: the owner has 50 tokens, while the remaining allowance is 70.
Disconnecting the site leaves that allowance in place. Receiving 20 tokens later brings the balance to 70 without creating a new approval. Those later-received tokens can therefore fall within existing spending authority. Finally, setting this allowance to zero does not return the 30 tokens already transferred.
A spending cap is not a safety guarantee
Wallet interfaces may describe a very large allowance as “unlimited.” The important point is that the amount can be far larger than the tokens you currently hold. It can avoid repeated approvals, but it also leaves more continuing authority with the spender.
An allowance limit concerns one permission relationship. It is not a guarantee that the spender is trustworthy, that its code cannot change or be exploited, or that the stated cap measures your maximum loss across every asset and permission. A smaller allowance does not make a malicious request harmless.
Likewise, a token’s ticker is not enough to identify the permission. The USDC network-label guide explains why asset names, networks and token representations need to be read separately. An ERC-20 explanation cannot be applied to native SOL or a Solana token merely because both appear in a wallet.
Signed approvals need their own checks
ERC-2612 adds a permit mechanism that can set an ERC-20 allowance using a valid signed message. Its conditions include the owner, spender, value, nonce, domain and deadline. Another address can submit the permit, so the owner need not personally submit an ordinary approve transaction for this mechanism to change the allowance.
The deadline limits when the permit can be accepted. It does not automatically put an expiry time on the allowance created by an accepted permit. Treating “the signature has a deadline” as “the spender’s permission ends at that deadline” would confuse two different conditions.
This is one named extension, not a description of every signed approval or every mechanism called a permit. The absence of an immediate gas charge when signing is not proof that a message is merely a harmless login. What matters is what the signed data authorizes and how it can be used.
Disconnecting and revoking solve different problems
MetaMask’s documentation distinguishes disconnecting a site from changing its token allowance. Disconnecting the basic connection does not erase an allowance recorded by the token contract.
Disconnecting also does not hide ordinary public Ethereum records. Someone who knows an address can still inspect its publicly recorded ETH balance, token holdings and transaction history using a block explorer. See Ethereum’s block-explorer documentation.
A submitted request to revoke is not the same as a completed state change. Changing one allowance also does not establish that every separate signed authorization or advanced permission has been canceled. Nor does it reverse a transfer that has already happened. This guide explains those distinctions without asking you to connect a wallet, sign a message or submit a transaction.
For the broader account-to-withdrawal workflow, see how to trade prediction markets. That workflow does not establish which token approvals a particular service or funding route currently requires; those requirements need that service’s own applicable instructions.
Frequently asked questions
Does connecting my wallet give a site a token allowance?
Basic connection alone does not create an ERC-20 allowance. A site can then request additional signatures or transactions, and a combined flow may include more than connection. Read each requested permission rather than assuming the first button describes the whole flow.
Is approving 100 tokens the same as sending 100 tokens?
No. In the example, approval sets an allowance of 100 while the balance stays at 80. Tokens move only in the later transfer. Permission and completed movement are separate records.
Can an allowance be larger than my balance?
Yes. A cap is not a balance check or a reserved pile of tokens. Existing authority can also matter for tokens received later, subject to the remaining allowance and the actual implementation.
Does disconnecting a site revoke its token approval?
No. The basic site connection and the token’s recorded allowance are separate. A completed change to the relevant allowance is a different action, and it does not undo past transfers.
Is a gas-free signature harmless, and does its deadline end an allowance?
Neither conclusion follows. Signed data can carry spending authority. For ERC-2612, the deadline limits acceptance of the permit; it does not automatically expire the resulting allowance. Other mechanisms require their own definitions and conditions.
Explore market questions
Read each market’s question, outcome rules and applicable service conditions. These general navigation links are separate from the fictional wallet-permission example.
Sources and scope
The ERC-20 standard defines approve, allowance, transfer and transferFrom. ERC-2612 defines the signed-permit extension and its acceptance conditions. MetaMask’s dapp guide, spending-cap explanation and revocation explanation provide wallet-specific context. The returned source texts were read on October 20, 2026. No live wallet, token contract or transaction was tested. The figures are original teaching illustrations with explicitly limited assumptions.
HypaForecast publishes educational guides and operates a prediction-market service. This guide does not establish which approvals any HypaForecast feature or funding route requires, support for a particular token or wallet, a security guarantee or a reader’s eligibility to use a service.
Share this guide