ERC-2612 adds a permit function to ERC-20 tokens so a holder can authorise a spender by signing a typed message off-chain instead of sending an approve transaction. Anyone — usually the dApp or a relayer — can submit that signature along with the action it enables, so a user can subscribe to a tokenized fund or pay into escrow in a single step without holding gas.
Key takeaways
- New functions:
permit(owner, spender, value, deadline, v, r, s),nonces(owner)andDOMAIN_SEPARATOR(). - Uses EIP-712 structured signatures, which wallets display in readable form.
- Eliminates the separate approval transaction — better UX and lower total gas.
- Phishing risk: a malicious permit signature can drain tokens; use short deadlines and exact amounts.
How permit works
- The dApp asks the user to sign an EIP-712 message: owner, spender, value, nonce, deadline.
- The user signs in their wallet — no transaction, no gas.
- The dApp’s contract calls
token.permit(...)with the signature, then immediatelytransferFromin the same transaction. - The token verifies the signature, checks the nonce and deadline, sets the allowance and increments the nonce.
Where it helps in tokenization
- Subscriptions: investors subscribe to a primary offering with one signature and one transaction — the platform can even submit it and sponsor gas.
- Delivery-versus-payment: escrow contracts pull stablecoins via permit at the moment securities are delivered. See DvP settlement.
- Recurring payments: pre-signed, time-bounded permits for scheduled payments (with care).
- Smart accounts: combine with ERC-4337 paymasters for fully gasless flows.
Limitations
- Token support: only tokens that implement ERC-2612 can use permit. Some major stablecoins support it; others do not or use different variants.
- Smart-contract wallets:
ecrecover-based permits do not work for contract wallets unless the token also supports ERC-1271. - Front-running: someone can submit a user’s permit first, causing the dApp’s call to revert; robust contracts check the existing allowance and proceed.
- Alternatives: universal approval contracts (e.g. Permit2) extend signature approvals to tokens without native permit.
Security best practices
- Request exact amounts and short deadlines.
- Show users exactly what they are signing; never request open-ended permits.
- Use well-audited implementations and correct domain separators (chain ID, contract address) to prevent replay.
- Monitor and educate users about permit-phishing.
The EIP-712 message an investor signs
{
"types": {
"Permit": [
{"name": "owner", "type": "address"},
{"name": "spender", "type": "address"},
{"name": "value", "type": "uint256"},
{"name": "nonce", "type": "uint256"},
{"name": "deadline", "type": "uint256"}
]
},
"primaryType": "Permit",
"domain": {"name": "USD Coin", "version": "2", "chainId": 1, "verifyingContract": "0xA0b8…eB48"},
"message": {"owner": "0xInvestor…", "spender": "0xSubscriptionContract…", "value": "250000000000", "nonce": 3, "deadline": 1792000000}
}
The wallet displays these fields so the investor can confirm the spender (your subscription contract), the exact amount and the deadline.
Subscribe-with-permit pattern
// Illustrative subscription entry point — not audited.
function subscribeWithPermit(uint256 amount, uint256 deadline, uint8 v, bytes32 r, bytes32 s) external {
try IERC20Permit(address(usdc)).permit(msg.sender, address(this), amount, deadline, v, r, s) {} catch {
// permit may have been front-run; continue if allowance is already sufficient
}
require(usdc.allowance(msg.sender, address(this)) >= amount, "allowance");
usdc.transferFrom(msg.sender, address(this), amount);
_recordSubscription(msg.sender, amount);
}
The try/catch handles the known front-running edge case gracefully.
UX guidelines
- Explain in plain language what the signature allows before showing the wallet prompt.
- Use deadlines measured in minutes, not days.
- Never request unlimited values for permits.
- Show a confirmation screen with the transaction hash after submission.
Frequently asked questions
No. The token contract must implement it. For other tokens, use approve or a universal permit contract.
The user pays no gas for the approval; someone still pays gas to submit the permit and action, often the platform.
No. Each signature includes a nonce that increments after use, and a deadline after which it expires.
They are as safe as the user’s judgement about what they sign. Use exact values, short deadlines and clear wallet prompts.
Only if the token is upgradeable. Otherwise use a universal approval contract such as Permit2.
EVM tokens deployed on Hedera can implement ERC-2612; native HTS tokens use Hedera’s own allowance model.
NUVZ is the RWA and Web3 engineering brand of ESS ENN Associates (est. 1993). Our team has designed and shipped tokenization platforms for real estate, education loans, solar PPAs, energy, carbon credits, bank deposits and trade documents. About us · Case studies
This article is for general information only and is not legal, tax or investment advice. Token standards evolve — always confirm the current status of an ERC at eips.ethereum.org and take advice from qualified counsel in each jurisdiction before issuing tokens.
