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
ERC-2612 adds `permit(owner, spender, value, deadline, v, r, s)` to ERC-20, letting a token holder authorize a spender via an EIP-712 signature instead of a separate `approve` transaction. The signature is submitted alongside the transferFrom call, collapsing two user-facing steps into one and eliminating the need for the owner to hold ETH for gas. Proposed by Martin Lundfall in April 2020, it ships with USDC, DAI, and most modern tokens. Uniswap's Permit2 provides equivalent UX for pre-2612 tokens at the cost of introducing a widely-trusted intermediary contract.
How ERC-2612 came to be.#
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.
How ERC-2612 and LSP relay and permission stack compare.#
| 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.