What is ERC-2612?
Gasless ERC-20 approval by signature - useful, but still allowance.
ERC-2612 is the standard behind "permit" in ERC-20 flows. Instead of sending approve first, the token holder signs an EIP-712 approval message and the app submits it alongside the action that needs the allowance.
on this page
The standard, in one card.
- Standard
- ERC-2612 / EIP-2612
- Extends
- ERC-20
- Signature format
- EIP-712 typed data
- Core function
- permit(owner, spender, value, deadline, v, r, s)
- Canonical spec
- eips.ethereum.org / EIP-2612
The origin story.#
Permit emerged from the same pressure that made ERC-20 allowances painful: users needed ETH to approve a token before they could use the token. ERC-2612 standardized the permit shape so wallets and protocols could support gasless approvals consistently.
What ERC-2612 actually is.#
function permit(
address owner,
address spender,
uint256 value,
uint256 deadline,
uint8 v,
bytes32 r,
bytes32 s
) external;
function nonces(address owner) external view returns (uint256);
function DOMAIN_SEPARATOR() external view returns (bytes32);
permit nonces · DOMAIN_SEPARATOR allowance · transferFrom permit verifies the owner's signature, checks the nonce and deadline, then writes allowance[owner][spender] = value. nonces prevents replay. DOMAIN_SEPARATOR binds the signature to a chain and token contract.
What's broken about ERC-2612.#
The approval transaction disappeared, but the approval risk did not. A bad spender, misleading typed-data prompt, or overbroad signed value still leaves a spender with transferFrom power.
-
Permit still creates allowance.#
The signature removes the approve transaction, but the end state is the same ERC-20 approval table. The spender still receives a value-limited permission inside the token contract.
ERC-2612permit(...) -> allowanceLSP6account permissionworkarounds tried- short deadlines
- exact values
- Permit2 scoped signatures
- approval revocation
-
Every token has to implement it.#
Permit is an ERC-20 extension, not a universal router. Tokens without ERC-2612 cannot be approved by this path, and implementations can diverge in domain separators, nonces, or wallet support.
ERC-2612token implements permitLSP25account relay callworkarounds tried- Permit2
- custom permit adapters
- fallback approve transactions
-
The signature is only as clear as the wallet UI.#
EIP-712 improves structured signing, but users still have to understand spender, value, nonce, and deadline. If the wallet renders the typed data poorly, permit can still become a phishing surface.
permitsign typed approvalLSP6named controllerworkarounds tried- human-readable wallet prompts
- simulation
- spender reputation
LUKSO designed it differently.#
LSP25 handles the "someone else pays gas" part at the account layer, while LSP6 handles "what may this signer do?" as account policy. That splits the two concerns ERC-2612 has to compress into one token-level permit.
- LSP25 Execute Relay Call Lets a controller sign a call that a relayer submits and pays for, without introducing token-specific permit extensions.
- LSP6 Key Manager Moves authorization policy to the account instead of embedding long-lived allowances in each token.
- LSP7 Digital Asset Fungible assets with operators, transfer data, and receiver hooks.
ERC-2612 vs LSP25+LSP6 in one table.#
| row | ERC-2612 | LSP relay and permission stack |
|---|---|---|
| primary goal | set ERC-20 allowance by signature | relay account execution and scope permissions |
| state changed | token allowance mapping | account call path / controller permission |
| gasless scope | approval only | any permitted account call |
| spender risk | still present | bounded by LSP6 permission |
FAQ.#
-
What does ERC-2612 add to ERC-20? #
It adds permit, nonces, and DOMAIN_SEPARATOR. permit lets an ERC-20 holder sign an approval off-chain and have someone else submit it on-chain.
-
Is ERC-2612 the same as Permit2? #
No. ERC-2612 is a token-level extension each token implements. Permit2 is an external shared approval contract from Uniswap that can support tokens even when they do not implement ERC-2612.
-
Does ERC-2612 make approvals safe? #
It improves approval UX and reduces the need for a separate approve transaction. The resulting permission is still ERC-20 allowance, so spender selection, amount, deadline, and wallet display still matter.