# ERC-2612: Permit Extension for ERC-20

Source: https://www.eipsfordesigners.com/standards/ERC-2612
Agent brief: https://www.eipsfordesigners.com/standards/ERC-2612/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/ERC-2612
Last reviewed: 2026-04-05
Last updated: 2026-04-05

| Field | Value |
| --- | --- |
| Status | Final |
| Chain | both |
| Category | Transaction Friction |
| Journey stages | Approving & Permissioning |
| Detailed guide | Yes |
| Official specification | https://eips.ethereum.org/EIPS/eip-2612 |
| Discussion search | https://ethereum-magicians.org/search?q=ERC-2612 |

## UX Impact

Token approvals via signature instead of transaction — users sign a message, relayer submits on-chain, no ETH needed for approval step. Design implications: replace 'Approve' transaction with signature request, show 'gasless approval' badge, display permit expiry/deadline clearly, warn about permit phishing (malicious sites requesting signatures). Design decisions: tradeoff between convenience (longer deadlines) and security (shorter expiry), must educate users that signatures can be dangerous, consider revoking stale permits in UI. Live for USDC, DAI, UNI, and aTokens but not universal. Addresses Redundant Token Approvals pain point (High severity) — separate approval is where most first-time DeFi users abandon.

## Summary

ERC-2612 adds "permit" to ERC-20 tokens. Instead of approve() + action as two transactions, users sign a permit message off-chain, then execute both in one transaction. The dApp submits the permit signature with the action. Result: one less transaction, one less confirmation, better UX.

## For Designers

- You can hide the separate approve tx by bundling permit with swap or deposit.
- You can show one Swap action while permit runs in the same transaction.
- You can surface token, amount, spender, and deadline in the signature preview.

## Applicability

### When to Use

- The token implements permit() and you want one-step swap or deposit flows.
- Users hesitate at separate approve transactions.
- You batch permit signature with the main action via relayer or router.

### When to Avoid

- The token does not support ERC-2612 (fall back to classic approve).
- Hardware wallet flows cannot sign typed data reliably.
- Regulatory or policy requirements mandate on-chain approve visibility.

## Problems It Solves

### Two transactions for any token interaction

Impact: critical

Old way: Approve → wait for confirm → swap → wait for confirm

New way: Sign permit → swap (approval included) → done

### Users pay gas for approval transactions

Impact: high

Old way: Pay $5 gas just to approve, before the actual swap

New way: Permit is a signature (free), bundled with action

### Approval UX is confusing

Impact: high

Old way: Why do I need to "approve" before I can "swap"?

New way: Single action from user perspective

## Anti-Patterns

### Permit with no deadline

Severity: critical

Permit valid forever, replay risk

Instead: Always set reasonable deadline (minutes, not days)

### Not explaining why there's a signature step

Severity: high

Users confused by "Sign" before "Confirm"

Instead: Clear UI: "Sign permit (free) then confirm swap"

### Falling back to approve without notice

Severity: medium

User suddenly has extra transaction, pays more gas

Instead: Warn: "This token doesn't support permit, using approval"

### Not supporting permit when available

Severity: medium

Users pay unnecessary approval gas

Instead: Check for permit support, use when available

## Design Decisions

### Do users see one action or two?

Recommendation: Present a single Swap (or Deposit) action; handle permit behind the scenes.

Rationale: Exposing permit as a separate step recreates the confusion ERC-2612 removes.

### What appears in the signature preview?

Recommendation: Show human-readable token, amount, spender, and deadline.

Rationale: Typed data must read like a transaction preview, not raw EIP-712 fields.

### What if permit is unsupported?

Recommendation: Fall back to classic approve with the same UI labels where possible.

Rationale: Graceful fallback avoids dead ends on older tokens.

### How do you handle expired permits?

Recommendation: Refresh deadline and ask for a new signature with clear expiry copy.

Rationale: Silent failures on stale permits look like app bugs.

## States to Design

### Permit signing

Trigger: Wallet prompts for EIP-712 permit signature.

User need: Understand this authorizes the upcoming action only.

Design response: Match swap preview copy; mention deadline date.

### Permit rejected

Trigger: User rejects typed data signature.

User need: Retry or use classic approve path.

Design response: Offer retry and "Approve in wallet" fallback.

### Executing with permit

Trigger: Relayer or router submits permit + action.

User need: Single progress indicator.

Design response: One loading state; do not flash separate approve step.

### Deadline expired

Trigger: Permit past deadline on chain.

User need: Know to sign again.

Design response: Explain expiry; regenerate permit with fresh deadline.

### Non-permit token

Trigger: Token lacks DOMAIN_SEPARATOR / permit.

User need: Complete flow without dead end.

Design response: Auto-route to standard approve flow with same CTA label.

## UI Components

### PermitSignButton

Button that initiates permit signature
States: idle, signing, signed, error
Props: token, amount, spender, deadline, onSign

### TwoStepFlow

Indicator showing sign → execute progress
States: not-started, signing, signed, executing, complete
Props: currentStep, steps[]

### GasSavingsDisplay

Shows how much user saves with permit
States: calculating, ready
Props: withoutPermit, withPermit, savings

## On Monad

### Gas Savings

Ethereum: Save ~$5-10 per avoided approval

Monad: Save less (gas already cheap) but still better UX

Design implication: Emphasize UX improvement over cost savings

### Confirmation Speed

Ethereum: Sign → wait → confirm → wait

Monad: Sign → confirm → instant done

Design implication: Flow feels much snappier

## Key Takeaways

- ERC-2612 = approve via signature, not transaction
- Reduces two transactions to one
- Always set deadline on permits
- Explain the sign step clearly to users
- Check if token supports permit before using

## UX Patterns

### Sign + Execute Pattern

Approve and action in single user flow

User flow:

- User enters swap details
- Click "Start Swap"
- Wallet shows permit signature request
- User signs permit (free)
- Wallet shows transaction confirmation
- User confirms transaction
- Swap executes with permit

Mockup registry key: `concept/permit-approval` (React UI on the live standard page).

### Permit vs Approve Comparison

Educate users on the improvement

User flow:

- First-time user sees "Sign Permit"
- Clicks "Why?" or info icon
- Modal explains gas savings
- User understands and continues

Mockup registry key: `concept/permit-approval` (React UI on the live standard page).

## Technical Notes

ERC-2612 adds permit(owner, spender, value, deadline, v, r, s) function to ERC-20. Owner signs EIP-712 typed data with nonce. Anyone can submit the permit. nonces(owner) increments to prevent replay. DOMAIN_SEPARATOR binds to contract. Compatible tokens: USDC, DAI, most new tokens.