Did you know?
Did you know? A token holder can sometimes give a smart contract permission to spend tokens by signing a message, without first paying for a separate on-chain approval transaction. That is what the ERC-2612 permit extension is designed to make possible. It is convenient, but the words “just sign a message” can hide a real spending permission.
Imagine Alicia has 100 fictional ART learning credits. She wants the school project app to use 12 credits for a class exhibition. The wallet asks her to sign a structured permit naming a spender, amount, deadline and particular token contract. Kai Kai can later submit that signed permission. Nothing has been transferred merely because the message was signed, yet an important authorisation may be waiting to be activated.
Quick answer: a valid ERC-2612 permit changes an ERC-20 allowance when someone submits it successfully to the token contract. The signature alone is not a completed transaction, and a permit is not itself a transfer. Nonces prevent repeated successful use of the same permit, while the deadline limits when it can be submitted—not necessarily how long the resulting allowance lasts.
Choose your reading route
- 1. Start with the ordinary ERC-20 approval
- 2. What does the owner sign?
- 3. A signature can exist before any blockchain transaction
- 4. The nonce is a one-use sequence control
- 5. The deadline limits submission, not necessarily later spending
- 6. Why the domain separator matters
- 7. Who pays the fee when the owner only signs?
- 8. Permit records an allowance; transferFrom moves tokens
- 9. A fictional school-club permit ledger
- 10. Read an explorer as a set of separate claims
- 11. A malicious spender can be hidden behind a familiar page
- 12. Why a permit can fail even with a genuine signature
- 13. Not every token called a ‘permit token’ follows ERC-2612
- 14. A guided question for three learners
- 15. Practical checks before a signed approval
- 16. Challenge question: an old signature reaches the contract
- Reader FAQ
- Primary sources and next reading
1. Start with the ordinary ERC-20 approval
An ERC-20 token usually separates ownership from delegated spending. A token owner calls an approval function to set an allowance for a spender. The spender may subsequently use transferFrom within the rules of the token contract and the available balance. Seeing a token in a wallet does not mean every website can spend it; a particular contract address must have a relevant authority.
In the familiar two-step flow, Alicia first sends an approval transaction and later initiates the action that uses it. These can require separate on-chain interactions and network fees. A permit changes the way the permission is recorded, not the fundamental distinction between authorising and actually moving a token.
2. What does the owner sign?
The EIP-2612 message includes the owner address, spender address, value, current owner permit nonce and deadline. It is signed using the EIP-712 typed-data method in the token’s specified domain. A wallet may render some of these fields as readable labels, but different wallet screens offer different levels of detail. Never treat a bright approval button as independent evidence that the spender is trusted.
The owner is not signing a bank mandate, an email instruction or the website’s marketing slogan. They are producing a cryptographic signature over specific structured data. If the signed details correspond to a valid permit on the intended token, the contract can later use that signature to authorise a specific allowance.
3. A signature can exist before any blockchain transaction
The signed bytes can sit in a browser, a server or a message sent to a relayer. Until someone submits a valid permit call to the contract and that call succeeds, the on-chain allowance need not change. It is therefore wrong to say that a signature is already a confirmed transfer; it is also wrong to say that an off-chain signature can never have on-chain consequences.
In the school example, Alicia signs permission for twelve ART credits at 2:00 pm. Kai Kai submits the permit at 2:03 pm. Only the accepted on-chain call updates the allowance. If Kai Kai never submits it, the permit may expire without ever creating that allowance. The distinction is permission prepared, permission accepted and permission exercised.
4. The nonce is a one-use sequence control
ERC-2612 has a per-owner nonce in the token contract. The contract checks that the nonce signed in the message matches the current value. When a permit succeeds, the nonce increases by one. Re-submitting the exact same signed permit then normally fails because its old nonce no longer matches. This is one layer of replay protection.
Do not confuse the permit nonce with the transaction nonce of the account that pays to submit the transaction. A relayer can have its own account transaction nonce while the owner signs a different token-specific permit nonce. Different token contracts also maintain their own permit state. A classroom exercise that gives all three values the same label will teach the wrong mechanism.
5. The deadline limits submission, not necessarily later spending
EIP-2612 requires the current block timestamp to be at or before the signed deadline when the permit is processed. A signature submitted after that deadline must revert. A near-term deadline therefore limits how long an unused permit can be held and submitted.
Here is the easily missed consequence: if a valid permit is submitted before its deadline and sets an allowance of twelve credits, that allowance does not automatically vanish when the deadline later passes. The deadline protects permit activation. It is not, by itself, an expiry date for the allowance created by a successful call. An owner must check the actual allowance and use the available revocation or replacement process where appropriate.
6. Why the domain separator matters
EIP-712 uses a domain to distinguish structured signatures belonging to different applications or verifying contracts. Depending on the implementation, relevant fields can include a protocol name, version, chain ID and verifying contract address. A correctly checked domain helps prevent a signed message for one contract being mistaken for the same instruction for another.
This is a protection mechanism, not a guarantee that the screen accurately communicates risk or that the requested permission is sensible. A protocol still needs application-specific replay controls such as the ERC-2612 nonce. EIP-712 explicitly does not provide replay protection by itself. A wallet must check the intended chain and contract rather than trust the website’s logo.
7. Who pays the fee when the owner only signs?
Somebody must pay for the on-chain call that consumes a permit. Often a relayer or application sponsors that call, or the permit is combined with another operation. The owner may avoid a separate approval transaction, but blockchain computation has not become costless. “Gasless” describes who pays or how interactions are bundled, not an absence of network fees.
A relayer can decide when to submit or withhold the signed permission within its validity window. The specification recognises that withholding risk and the relevance of deadlines. A transaction can also fail for ordinary reasons such as insufficient gas, a changed nonce or expired deadline. Show students the actual submitted transaction rather than an advertisement about free clicks.
8. Permit records an allowance; transferFrom moves tokens
Suppose Alicia has 100 ART credits and successfully authorises the workshop contract to spend twelve. Her token balance can remain 100 immediately after the permit, while the workshop’s allowance becomes twelve. Later, an authorised transferFrom operation might move five credits to the specified destination, assuming the contract rules and balance permit it.
After a conventional ERC-20 transferFrom of five against an allowance of twelve, the allowance is generally reduced, subject to contract rules and exceptions such as maximum allowances. One cannot infer actual movement from seeing only an Approval event. Check balances, the state-changing transaction and the appropriate Transfer log when interpreting what happened.
9. A fictional school-club permit ledger
The following numbers are invented for learning and are not observed blockchain balances. Alicia has one hundred ART credits. Kai Kai acts as a relayer, while the exhibition contract is the spender. The exercise asks students to track balance, allowance and permit nonce as separate quantities. A signature does not subtract tokens, and an expired but already-consumed deadline does not automatically erase an allowance.
Cover the “meaning” column and ask whether each row proves permission, a transfer or neither. The distinction forces readers to identify which operation changes which piece of state.
| Time | Illustrative action | ART balance | Allowance | Owner permit nonce | Meaning |
|---|---|---|---|---|---|
| 14:00 | Alicia signs permit with nonce 7 | 100 | 0 | 7 | Signature exists, no accepted state change |
| 14:03 | Kai Kai submits permit successfully | 100 | 12 | 8 | Allowance created; no transfer yet |
| 14:05 | No transferFrom has occurred | 100 | 12 | 8 | Signing deadline does not burn permission |
| 14:10 | Spender transfers 5 ART | 95 | 7 (ordinary case) | 8 | Balance moves after a separate valid call |
| 15:01 | Someone resubmits original signature | 95 | 7 | 8 | Old nonce, and potentially deadline, make replay invalid |
10. Read an explorer as a set of separate claims
A block explorer may show a successful permit transaction, decoded parameters and an Approval event. These can establish that the token contract accepted an allowance-changing call, provided the chain, contract and transaction are genuine and final to the required level. They do not prove that the spender is a good business or that a subsequent off-chain purchase was delivered.
If a website says “payment completed” immediately after permit, ask for the separate payment evidence. Did transferFrom execute successfully? Which tokens and amount moved? To which address? Was the subsequent order fulfilled? A transaction identifier can narrow the evidence, but it cannot answer external business questions on its own.
11. A malicious spender can be hidden behind a familiar page
The spender field is an address. It may be a contract controlled by a real service, an outdated integration or a malicious operator. Users should not infer trust from a copied token symbol, a well-designed site or a familiar wallet brand. The permission value also matters: a very large allowance creates a larger exposure than a narrowly bounded one, subject to balance and contract behaviour.
Check the verifying contract, destination chain, spender, allowance amount and deadline before signing. If any important field is unclear, do not sign as a test. This guide is for understanding the mechanism; it does not recommend granting token approvals or connecting a wallet to an unfamiliar project.
12. Why a permit can fail even with a genuine signature
A permit can revert if it is past deadline, uses the wrong nonce, names a zero owner address, or cannot be validated under the expected domain and signature conditions. The website may also submit the wrong token contract or an incompatible permit variant. A signature can be mathematically sound yet wrong for this particular authorisation.
After a failed permit, avoid declaring that an allowance changed. Check the current nonce and allowance with the actual token contract. If a relayer submits a permit after another party has already used the same nonce, the later call should fail. A “transaction failed” status and a successful accepted permission are not interchangeable.
13. Not every token called a ‘permit token’ follows ERC-2612
Some systems use the standard ERC-2612 interface, while others use earlier or different signed-approval formats. For example, a well-known DAI-style permit has different parameters and semantics. The fact that a button says “Permit” does not guarantee the user is looking at this specification or that the allowed value behaves exactly the same way.
Look at the verified contract implementation and the exact message being signed. Token decimals, spender addresses and the EIP-712 domain all need careful interpretation. A tutorial should avoid teaching a signature format as if every asset on every blockchain implemented it identically.
14. A guided question for three learners
Alicia signs a permit for twelve ART credits with a deadline of 15:00 and nonce seven. Kai Kai submits it at 14:55; it succeeds and changes the nonce to eight. At 15:10 the allowance is still twelve because no spending call has occurred. At 15:15 Tricia says the permit must have expired and all permission disappeared. Her interpretation is incorrect: the unused signature expired, but the successfully created allowance persists until changed under the token rules.
Ask learner one to track the nonce, learner two to track balance and learner three to track allowance. Then have everyone solve the changed case independently: what happens if Kai Kai tries to reuse nonce seven at 15:20? The repeated permit cannot pass the nonce and deadline checks. The teaching gain comes from separating states, not memorising the word “replay”.
15. Practical checks before a signed approval
Record five questions: Which chain? Which token contract? Which spender? What allowance value? What deadline? Then add a sixth: what will the application do with that allowance, and how can it be reduced or revoked later? Comparing a website’s description with the fields in the wallet is a useful defence against mistaken authorisation.
Even strong checks cannot guarantee safety. A spender contract may be upgradeable, code may have bugs, or external obligations may be misrepresented. Use low-risk demonstrations with fictional tokens when learning. Never paste a real seed phrase, private key or signed approval into an educational form.
16. Challenge question: an old signature reaches the contract
Imagine an unused permit signed at noon, valid until 18:00. At 15:00 the owner visits the project again but merely disconnects the website. If the original signed message remains valid and reaches the contract before 18:00, disconnecting the site’s browser session does not necessarily prevent its use. The owner must assess the permit’s nonce, deadline and on-chain state, not merely which tab is open.
Now suppose the permit was already consumed at 14:00. Reusing the same bytes should fail on the nonce, but the on-chain allowance from 14:00 may still remain. These opposite cases show why a security check has to distinguish an unsubmitted signature from an allowance already created.
Reader FAQ: six answers to keep
Is an ERC-2612 permit a free token transfer?
No. It is a signed-approval mechanism. Submitting the permit costs gas to someone, and a separate permitted operation is needed for transfer.
Does a permit’s deadline make the allowance expire?
Not under the standard’s basic semantics. The deadline decides whether the signed permit can still be submitted. The allowance created by successful submission remains until updated or consumed under token rules.
Does a nonce always equal my wallet’s transaction nonce?
No. EIP-2612 uses its own permit nonce for each owner in the token contract. The account sending an on-chain transaction has a different transaction nonce.
Can another person submit my signed permit?
Yes, generally any party with the signed message can submit it if all checks pass; the effect is the allowance the owner signed for. This is why the exact message, spender and deadline matter.
Does EIP-712 alone prevent every replay attack?
No. EIP-712 provides structured hashing and domain separation. The application needs a replay-control design; ERC-2612 uses a nonce and deadline.
Does a successful Approval event mean the goods were delivered?
No. It provides evidence of the approval path, not of a later token transfer or an external purchase being fulfilled.
Primary sources and next reading
- How Blockchain Works: the learning hub
- Why token approvals can outlive a website
- Why signing a message differs from sending a transaction
- Why disconnecting does not revoke permissions
- ERC-2612 permit specification (primary source)
- EIP-712 typed-structured-data signing (primary source)
Scope note: The ART credits, classroom participants and times above are fictional teaching examples, not wallet activity, research observations or a recommendation to buy tokens. ERC-2612 applies to implementations that follow its rules. Check the actual contract, chain and current protocol documentation before treating a live interaction as safe.