Permit Signature (EIP-2612)

What Is a Permit Signature?

A permit signature is an off-chain authorization mechanism for ERC-20 tokens, standardized as EIP-2612. Instead of calling the traditional approve() function on-chain (which requires a transaction and gas), the token holder signs a structured message granting a spender permission to transfer a specific amount of tokens. Anyone can then submit that signature to the token contract's permit() function to set the allowance on-chain.

The standard was authored by Martin Lundfall and finalized in October 2022. It was inspired by MakerDAO's DAI token, which shipped a non-standard permit() function in November 2019 as part of the Multi-Collateral DAI launch. EIP-2612 generalized DAI's approach into a specification any ERC-20 token can implement.

The core insight is simple: the traditional ERC-20 workflow forces users into two separate transactions (approve, then transferFrom), doubling gas costs and degrading user experience. Permits collapse this into a single transaction by moving the approval step off-chain.

How It Works

EIP-2612 extends the ERC-20 standard with three new functions on the token smart contract:

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)

The permit() function accepts a signature and sets the token allowance accordingly. The nonces() function tracks a per-address counter to prevent replay attacks. The DOMAIN_SEPARATOR() binds signatures to a specific token contract and chain.

The Signing Process

When a user wants to approve a spender without paying gas, the flow works as follows:

1. The application constructs an EIP-712 typed data message containing the owner address, spender address, token amount, current nonce, and a deadline timestamp
2. The user's wallet displays the structured data in a human-readable format and asks for confirmation
3. The user signs the message off-chain, producing the v, r, and s signature components
4. The application (or a relayer) submits the signature to the token contract's permit() function along with the original parameters
5. The contract reconstructs the EIP-712 digest, recovers the signer via ecrecover, verifies it matches the owner, checks the nonce and deadline, then sets the allowance
6. The nonce increments, invalidating any reuse of the same signature

EIP-712 Typed Data

The signature follows the EIP-712 standard for typed structured data hashing, which is critical for both security and usability. The signed message includes:

// EIP-712 domain separator
EIP712Domain(
    string name,        // Token name (e.g., "USD Coin")
    string version,     // Contract version
    uint256 chainId,    // Prevents cross-chain replay
    address verifyingContract // Token contract address
)

// Permit struct
Permit(
    address owner,      // Token holder
    address spender,    // Approved address
    uint256 value,      // Token amount
    uint256 nonce,      // Replay protection
    uint256 deadline    // Expiration timestamp
)

The domain separator ensures that a permit signed for USDC on Ethereum cannot be replayed against USDC on Polygon or any other chain: the chainId and verifyingContract fields produce a different digest.

Comparison with Traditional Approval

Token Support

Not all ERC-20 tokens support EIP-2612. The token contract must implement the permit() function natively. Major tokens with support include:

• USDC: Circle added EIP-2612 support with the USDC v2.0 upgrade in 2022, deployed across all chains where Circle issues native USDC
• DAI: MakerDAO's original implementation predates the standard and uses a slightly different interface (a boolean allowed parameter instead of a uint256 value)
• UNI, AAVE, and most tokens built with OpenZeppelin's ERC20Permit extension

Notable tokens without native permit support include WETH, USDT, and older contracts deployed before the standard was widely adopted. Uniswap's Permit2 contract addresses this gap.

Permit2: Universal Gasless Approvals

Uniswap Labs released Permit2 in November 2022 to extend permit-style approvals to all ERC-20 tokens, even those without native permit() support. The mechanism works in two steps:

1. The user calls the standard approve() once to grant the Permit2 contract an allowance on each token
2. For all subsequent interactions with any DApp that integrates Permit2, the user signs off-chain Permit2 signatures instead of submitting new approval transactions

Permit2 is deployed at the same deterministic address across Ethereum, Optimism, Arbitrum, Polygon, and other chains. It is immutable, unowned, and has been audited multiple times. Major DeFi protocols including 1inch, CoW Swap, and 0x have adopted it.

Use Cases

Gasless DeFi Interactions

Permits are foundational to gasless DeFi workflows. A user can sign a permit and a swap intent off-chain, then a solver or relayer submits both in a single transaction using their own ETH for gas. The user receives the output token without ever holding ETH. This pattern powers intent-based trading protocols and gasless swap interfaces.

Meta-Transactions

Third-party relayers can submit permit signatures on behalf of users, paying gas costs themselves and recovering the expense through other means (protocol fees, gas tokens, or subsidized onboarding). This enables fully gasless onboarding flows where new users interact with DeFi protocols without needing to acquire ETH first.

Smart Wallet Integration

Account abstraction wallets and smart wallets use permit signatures for session keys and batched operations. An ERC-4337 bundler can wrap a permit signature inside a UserOperation, letting the bundler pay gas while the user authorizes token spending with a simple signature.

Single-Transaction Token Operations

DeFi protocols can combine permit() and the subsequent action (swap, deposit, repay) into a single transaction. Instead of the user approving tokens in one transaction and depositing in another, a router contract calls permit() and transferFrom() atomically. This halves the number of transactions users need to confirm.

Security Risks

Permit Phishing

Permit phishing has become one of the most common and costly attack vectors in crypto. The attack works as follows:

1. An attacker creates a fake website mimicking a legitimate DeFi protocol or sends a malicious link via social media
2. The victim is prompted to sign what appears to be a routine EIP-712 message, but is actually a permit granting the attacker unlimited allowance over the victim's tokens
3. Because signing is off-chain and free, there is no gas cost or on-chain transaction to alert the victim
4. The attacker obtains the signed permit, submits it on-chain along with transferFrom(), and drains the victim's tokens in a single transaction

This is more dangerous than traditional approval phishing because possession of the signature alone grants full authorization: the attacker can execute everything in one atomic transaction with no prior on-chain footprint.

Scale of Losses

According to ScamSniffer's annual reports, permit-based phishing caused massive losses in 2024:

• Wallet drainer scams totaled roughly $494 million across 332,000 victims, a 67% increase year-over-year
• Permit signatures were the primary method in 56.7% of cases exceeding $1 million
• The largest single-victim attack drained $55.47 million in DAI in August 2024 using a signed message that transferred vault ownership to the attacker
• In 2025, losses dropped 83% to roughly $84 million across 106,000 victims, attributed to improved wallet security warnings and user education

Why Permits Are Especially Dangerous

Several properties of permit signatures make them attractive to attackers:

• Signing is invisible on-chain: unlike an approve() transaction that appears in the user's transaction history, a signed permit leaves no trace until the attacker submits it
• No gas cost to the victim: the act of signing feels low-stakes compared to confirming a transaction
• Wallets display EIP-712 data in a structured format, but many users do not read the spender address or token amount before signing
• Attackers can batch multiple permit signatures and drain multiple tokens in a single transaction

Mitigations

Protecting against permit phishing requires awareness at multiple levels:

• Always verify the spender address and token amount in the EIP-712 signing prompt before confirming
• Use wallet software that flags suspicious permit requests and displays clear warnings about token approval scopes
• Revoke unused token approvals regularly using tools like Revoke.cash or Etherscan's token approval checker
• Set short deadlines on permits to limit the window during which a leaked signature remains valid
• Never sign permit messages on unfamiliar websites or from unsolicited links

Why It Matters

Permit signatures represent a fundamental tradeoff in blockchain UX design: they dramatically improve the user experience of token interactions while simultaneously creating a new class of social engineering attacks. The same property that makes permits powerful (off-chain, gasless authorization) is what makes them dangerous (invisible, low-friction signing).

For DeFi protocols and wallet builders, understanding permits is essential. Modern embedded wallet designs must balance the UX benefits of gasless approvals against the security risks of off-chain signing. Solutions like AI-powered wallet security and improved signature verification UI are active areas of development.

As stablecoins like USDC and DAI adopt permit support across multiple chains, the standard continues to shape how users interact with decentralized finance. The challenge for the ecosystem is preserving the UX gains while building better defenses against the phishing attacks that exploit them.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.