An ERC-20 allowance gives a designated spender permission to withdraw a specified amount of tokens, but does not authorize other tokens or automatically transfer funds. ERC-2612 permits use s
An ERC-20 allowance gives a designated spender permission to withdraw a specified amount of tokens, but does not authorize other tokens or automatically transfer funds.
ERC-2612 permits use signed messages to establish on-chain allowances, with fields such as owner, spender, value, nonce, and deadline defining the authorization.
A permit deadline only limits when a signature can be accepted; once the allowance is established, it remains active until spent, replaced, or otherwise revoked under the token’s rules.
Learn what token approvals and permit signatures actually authorize, how ERC-20 allowances work, and why a permit deadline does not automatically expire spending permission.
An ERC-20 allowance belongs to a specific relationship inside a token contract: owner, spender, and remaining amount. The standard’s approve function sets the amount, while allowance reports how much the spender is still permitted to withdraw. Calling approve again replaces the existing value rather than adding to it. The authorization can cover multiple withdrawals whose combined amount fits the allowance. ERC-20: approve and allowance.
The corresponding transferFrom function transfers tokens from one address to another under an authorization mechanism. In the usual allowance model, the spender exercises the owner’s permission through that function. Approval and transfer are separate operations: establishing the allowance does not, by itself, transfer tokens or reserve a portion of the owner’s balance. ERC-20: transferFrom.
Consider an illustrative owner with 100 tokens and a finite allowance of 60 for a spender. If an ordinary allowance-consuming implementation processes a withdrawal of 25, the owner’s balance becomes 75 and the remaining allowance becomes 35. Another withdrawal can use that remaining permission without a new approval. This example assumes a plain token with no transfer fee or other custom balance behavior.
The allowance does not record the commercial purpose behind a transaction. ERC-20’s approval fields do not specify a purchase, destination address, exchange rate, minimum output, or particular application action. A spender contract may impose such restrictions in its own code, but they are additional rules outside the basic allowance. A recognizable application label therefore does not explain the full scope of the underlying authorization. ERC-20 function definitions.
The authority is also token-specific. Permission recorded by one token contract does not, through ERC-20 alone, authorize another token or the account’s native ETH. Within the approved token, however, the allowance is not tied to the balance at the moment of approval. If permission remains and the owner’s balance later increases, those newly received tokens may also be transferable under it, subject to the token’s actual execution rules. This follows from the standard’s separate balance and allowance records.
ERC-2612 changes how an allowance can be authorized. Rather than deriving the owner solely from the caller of approve, the token contract verifies an owner’s signature over a structured permit message. The extension adds permit, nonces, and DOMAIN_SEPARATOR to the ERC-20 interface. ERC-2612 specification.
The mechanism has 3 distinct stages:
The permit operation itself changes authorization, not token ownership. An application may execute a permit and a subsequent token transfer within the same transaction, but that transfer is an additional operation. This is why an interaction can move funds shortly after a signature is supplied even though the permit’s direct effect is only an allowance update.
The same distinction qualifies the phrase “gasless approval.” The owner can produce the signature without sending the approval transaction, while someone else submits the on-chain call. Execution still occurs on-chain; ERC-2612 does not make it costless or guarantee that a relayer will submit it. The standard explicitly recognizes that a relayer can withhold a permit. ERC-2612 rationale.
The signed permit structure contains owner, spender, value, nonce, and deadline. Its interpretation also depends on the EIP-712 domain used by the verifying token contract. Each element answers a different authorization question. ERC-2612 signed message.
Owner: whose tokens are subject to the permission? This is the account whose allowance is changed and whose signature must validate. The person or address submitting the transaction does not become the owner merely by presenting the permit.
Spender: which address receives the authority? This is the approved spender, which may differ from the transaction submitter, the website operator, and any eventual token recipient. ERC-2612 does not bind submission to a particular relayer.
Value: how much allowance will be recorded? The value is the new allowance, not a guaranteed transfer amount and not an increment to an existing allowance. Token quantities use integer units. ERC-20’s optional decimals metadata explains how those units can be displayed; an apparent amount cannot be interpreted accurately without the relevant denomination. ERC-20: decimals.
Nonce: which authorization state must still be current? ERC-2612 tracks a nonce for each owner within the token contract. A successful permit consumes the current nonce by increasing it. Merely creating a signature does not consume it. If 2 permits are signed against the same current nonce, accepting 1 prevents the other from subsequently satisfying that nonce check. The counter is not a global sequence across every token or chain. ERC-2612 specification and rationale.
Deadline: until when may the contract accept this permit? The check uses the block timestamp, with equality allowed. It applies at permit execution, rather than starting a countdown when the owner signs.
Domain: in which contract and chain context should this signature mean anything? ERC-2612 requires an EIP-712 domain separator and says it should distinguish the contract and chain. Its common example includes name, version, chainId, and verifyingContract. These 4 fields are a common construction, not an identical field list mandated for every implementation. EIP-712 defines a general domain framework; ERC-2612 adds the particular permit semantics and nonce mechanism. ERC-2612 domain construction; EIP-712 domain definition.
Structured signing makes the content interpretable, but the field names alone do not establish the trustworthiness of a spender or the correctness of a deployed contract. EIP-712 itself expressly does not provide replay protection. In ERC-2612, protection depends on the permit rules, nonce checks, domain construction, and their implementation working together. EIP-712 abstract.
Consider a hypothetical example on November 15, 2026, during Eastern Standard Time: a permit authorizes an allowance of 100 tokens and has a deadline of 12:00 p.m. ET (GMT−05:00). If the contract accepts it at 11:59 a.m. ET (GMT−05:00), the allowance is set to 100. At 12:01 p.m. ET (GMT−05:00), the passing deadline does not erase that allowance. The deadline governed acceptance of the signed message; ordinary ERC-20 allowance state has no expiry field. ERC-2612 permit conditions; ERC-20 allowance interface.
If the permit has not been accepted and the current block timestamp is later than that 12:00 p.m. ET (GMT−05:00) deadline, it can no longer pass ERC-2612’s deadline check. These are different outcomes: an unused authorization can become unacceptable while an allowance already created from it remains in place.
A finite allowance may subsequently be consumed by spending or replaced by another allowance update. Neither its persistence nor its amount can be inferred from the original deadline alone. Likewise, completion of the activity that motivated an approval does not automatically remove whatever allowance remains. An application or token can implement additional expiration rules, but those must be established separately.
The standard itself documents why the distinction matters. Its compatibility discussion describes a different permit implementation that makes transfers conditional on an expiry timestamp. That behavior is contrasted with ERC-2612’s specified mechanism, rather than being a universal property of permit signatures. ERC-2612 backwards compatibility.
Allowances are mutable state, so the order in which calls execute matters. Replacing an allowance of 100 with 20 does not inherently mean that only 20 tokens can be spent across the entire transition. If the spender uses the old allowance before the replacement is processed, a later update can still establish the new allowance of 20. ERC-20 warns about this approval race, and ERC-2612 explicitly says it also applies to permit. ERC-20 approval warning; ERC-2612 security considerations.
Another timing issue concerns unused signatures: a current allowance and an unused permit signature are different things. In the basic standards, changing an allowance with approve is not specified to advance the ERC-2612 nonce. A still-valid, unconsumed permit can therefore later replace that allowance if its conditions remain satisfied. Consequently, a zero allowance at a particular block does not, by itself, prove that no outstanding signature could establish a new allowance. A token may add other invalidation behavior, but that would need separate verification.
The transaction submitter also has no exclusive claim over a permit signature. Another address can submit the same valid permit first. The specified allowance effect remains bound to the signed owner, spender, and value, but timing can affect a broader application workflow that expected to submit the permit itself. ERC-2612 recognizes this front-running possibility; it does not guarantee the success of every surrounding application action. ERC-2612 security considerations.
These timing distinctions explain why “signed,” “submitted,” “accepted,” and “spent” describe different facts. A signature is not proof of inclusion, an Approval event is not proof of a transfer, and a transfer is not proof that the spender has no remaining authority.
ERC-20 does not require every token to support ERC-2612. Nor does a function named permit establish that it uses ERC-2612’s exact message or semantics. The standard’s compatibility section describes a DAI-style variant using a Boolean allowed field instead of a numeric value, with a differently named expiry field. Such differences affect the signed message and cannot be treated as cosmetic. ERC-2612 backwards compatibility.
Allowance accounting also has implementation conventions. OpenZeppelin Contracts 5.x documents that its ERC20 implementation does not reduce an allowance set to the maximum uint256 value when transferFrom executes. It treats that value as an infinite approval. This is an implementation-specific behavior to verify, rather than a reason to assume that every token handles every large allowance identically. OpenZeppelin ERC20 reference.
Additional token rules can affect whether an otherwise authorized transfer succeeds. Sufficient allowance does not establish that the owner has enough balance, or that the actual token and spender implementations will permit the requested operation. Extensions and custom logic remain relevant even when the visible interface looks familiar.
Domain handling has its own limits. ERC-2612 warns that caching a domain separator containing a chain ID at deployment can create replay risk if a later chain split changes the relevant context. A familiar domain field is therefore evidence of intended binding, not a blanket assurance about how every deployment behaves. ERC-2612 security considerations.
Different evidence answers different questions. The signed message identifies the proposed authorization. A successful permit execution establishes that the contract accepted that authorization at that point. The allowance read at a specified block identifies the remaining authority then. The transaction’s executed calls, read alongside token transfers, can establish whether that allowance was exercised.
Events help reconstruct activity, but they are not interchangeable with current state. ERC-20 requires an Approval event for a successful approve, and ERC-2612 requires one for a successful permit. Neither rule means every later allowance change must produce the same event. OpenZeppelin’s ERC20 implementation, for example, documents that it omits Approval events for allowance consumption during transferFrom. ERC-20 events; ERC-2612 specification; OpenZeppelin ERC20 reference.
An allowance reading also cannot reveal every signature that may exist off-chain. Without a specific token deployment, chain, signed payload, and execution history, the standards alone cannot establish whether a particular authorization is currently usable or what additional application rules apply.
The useful model is to follow the authority through its stages: a signature proposes a precisely scoped allowance update; successful validation records it; later execution may consume it. The permit deadline constrains the first transition. It does not close the spending permission that transition creates.
For information only, not financial, investment or legal advice.
Markets involve risk. Verify current information before making decisions.
Opinions are the authors’ own and do not guarantee future results.
Looking for the latest scoop and cool insights from CoinRank? Hit up our Twitter and stay in the loop with all our fresh stories!
〈Token Approvals & Permit Signatures: What an Allowance Actually Authorizes〉這篇文章最早發佈於《CoinRank》。
