In the world of blockchain, users often need to grant permissions (allowances) that let smart contracts spend tokens on their behalf. For example, when using a decentralized exchange (DEX) to swap tokens, a user must first authorize the exchange contract to transfer a specific amount of tokens from their wallet. Under the traditional ERC-20 standard, this process requires two separate on-chain transactions: one for approval and another for the actual token transfer. This two-step process is not only cumbersome but also incurs additional gas fees. To improve both user experience and security, the Ethereum community introduced a signature-based authorization mechanism, Permit (such as EIP-2612), and later developed an advanced version called Permit2. These new mechanisms allow users to grant token approvals through off-chain signatures, avoiding the need for extra on-chain transactions.

In this article, we’ll start with the basics by explaining how traditional ERC-20 approvals work and their limitations. Then, we’ll dive into how Permit and Permit2 function, highlight their benefits and trade-offs, and discuss how they enhance both efficiency and security. We’ll also examine potential security risks, particularly phishing attacks involving malicious signatures, and offer tips for staying safe. Whether you’re new to blockchain or just starting your crypto investment journey, this guide aims to help you understand these important technical innovations.

Fundamentals of the ERC-20 Authorization Model

Before diving into Permit, let’s first take a look at how the traditional ERC-20 token authorization model works, and the limitations it presents.

How Traditional ERC-20 Approvals Work

ERC-20 is the standard for tokens on Ethereum. It defines functions like approve and transferFrom, which together enable token authorization. Authorization here means that a token holder (the owner) allows another account, typically a smart contract (the spender), to transfer a certain amount of tokens on their behalf. The basic process works like this:

1. The token holder calls the token contract’s approve(spender, amount) function. This records the allowance in the contract’s internal mapping, usually expressed as allowance[owner][spender] = amount. For example, if user A authorizes the Uniswap contract to spend up to 100 tokens, the contract will store allowance[A][Uniswap] = 100. This step requires an on-chain transaction and gas fees paid by A.
2. Delegated Transfer (transferFrom): Later, when Uniswap (or another dApp) needs to spend tokens on behalf of A, it calls transferFrom(A, B, amount) on the token contract. The contract checks whether allowance[A][Uniswap] is sufficient. If it is, the contract transfers the specified amount from A to B and deducts that amount from the allowance.

Limitations and Challenges of the Approve Model

The two-step model above allows users to authorize contracts to manage their funds, without ever sharing their private keys. However, this traditional approach also comes with several practical issues:

Two transactions required, poor user experience
Each time a user wants to use a new token on a dApp, they must first send a separate approval transaction before they can actually perform the desired action (like swapping or staking). This means their wallet will prompt them twice for confirmation and charge additional Gas fees. For beginners, this extra step can be confusing and inconvenient.

Fragmented approval management
When users interact with multiple dApps using the same token (e.g., trading on Uniswap and then depositing into a different DeFi protocol), each dApp requires a separate approval, even though it’s the same token in the same wallet. This leads to repetitive approvals, wasting time and gas.

Moreover, since each dApp manages its own allowances independently, users have little centralized control over their approvals. Some tools, such as Revoke.cash and DeBank, allow users to view and manage token allowances, but many users aren’t aware of them. And even if they are, revoking permissions still requires an on-chain transaction, which adds cost. As a result, many old or unused approvals are simply forgotten.

The risks of unlimited approvals
To avoid frequent approval transactions, many dApps suggest users grant unlimited approval, allowing the contract to spend the user’s entire token balance, with no expiration. While this approach saves effort later, it introduces serious security risks: if the dApp or contract is compromised, an attacker could drain all of the approved tokens.

These challenges have prompted developers to seek better alternatives. Ideally, users should only need to sign once (preferably off-chain and gas-free) to complete both approval and action. The approval should also be limited in scope and duration to minimize potential risks. This is the motivation behind the introduction of ERC-20 Permit.

Permit: Signature-Based ERC-20 Authorization (EIP-2612)

The concept of Permit was first introduced by the DAI stablecoin contract and later standardized as EIP-2612. In short, Permit allows users to authorize token transfers using off-chain signatures, eliminating the need to send a separate on-chain approve transaction. Let’s take a closer look at how it works and its distinctive features.

How Permit Works

Permit is an authorization mechanism based on digital signatures. Under the EIP-2612 standard, ERC-20 token contracts that support Permit add a function called permit() which looks like this:

function permit(
address owner, address spender,
uint256 value, uint256 deadline,
uint8 v, bytes32 r, bytes32 s
) external;

Here, owner, spender, and value specify who gives permission, who receives permission, and the amount allowed. deadline indicates when the signature expires. The parameters v, r, and s form the ECDSA digital signature. Using Permit, users bypass the separate on-chain approval—they simply sign the message (without paying Gas) and include this signature with their transaction to complete the authorization in one step.

Permit Workflow

Compared to traditional approve, Permit removes the need for an extra on-chain transaction, saving both time and Gas fees. It also enables fine-grained control over approvals. For instance, a user could sign a Permit that allows spending exactly 50 USDC, valid for only 5 minutes. Even if the signature is exposed, it becomes unusable after the deadline, reducing risk. Today, many DeFi protocols, such as decentralized exchanges and lending platforms, already support Permit. Well-known examples include Uniswap V2/V3 LP tokens, DAI, and USDC, which have implemented the EIP-2612 standard, enabling one-step, signature-based approvals.

However, the biggest limitation of Permit is that it must be implemented directly within the token contract. If a token’s developer hasn’t added the permit() method—meaning it doesn’t support EIP-2612—then Permit simply cannot be used. Since EIP-2612 was only introduced in 2020, many older tokens don’t include it, and even newer tokens don’t always adopt it. This restricts the applicability of Permit: unsupported tokens still require the traditional approve flow.

Another issue is that wallet software must properly handle and display Permit signatures, which are typically formatted using EIP-712. Most major wallets support this now, but some still show raw data instead of human-readable messages, making it hard for users to understand what they’re signing. Without a clear interface for EIP-2612, wallets may hinder users’ understanding of signature-based approvals. Furthermore, in cases of parallel deployments (such as contracts with identical addresses on different chains), signatures could potentially be reused in other environments. Therefore, users must verify that the chain ID and contract address in their signatures match their current environment to prevent permissions granted for tokens on Chain A from being misused by identical contract addresses on Chain B.

In essence, Permit significantly improves the efficiency and flexibility of ERC-20 approvals, marking a major milestone in gasless approval mechanisms. However, it’s not a perfect solution: it requires token-level support, and it introduces new risks. Next, we’ll examine how Uniswap’s Permit2 builds upon and extends the foundation laid by Permit.

Permit2: Universal Authorization Management Contract

As the Permit mechanism gained popularity, a new challenge emerged: how to extend the convenience of signature-based authorization to tokens that don’t support Permit? To address this issue and optimize authorization experiences across various scenarios, the Uniswap team introduced Permit2 in 2022. Unlike a token-specific feature, Permit2 is a standalone authorization management smart contract. It acts as an intermediary for token authorizations, providing unified and enhanced permission functionality. Let’s analyze the principles and features of Permit2.

How Permit2 Works

Permit2 functions as an authorization relay service. Its core concept is simple: users grant a one-time approval to the Permit2 contract, which then manages subsequent sub-authorizations to various applications. Here’s how it works:

1. One-time Permit2 Authorization: Users approve Permit2 for each token using the traditional approve(Permit2, max_amount) method. A large or unlimited amount is recommended since this is the master approval. Once completed, the Permit2 contract gains the ability to call transferFrom on behalf of the user for that token. This requires an on-chain transaction but only needs to be done once.
2. Off-chain Signature for Sub-authorization: When users want to interact with a DApp (for example, using Uniswap Universal Router for multi-token swaps), they sign an off-chain authorization message following Permit2’s specifications. This signature includes details like the permitted token, amount, target spender (such as a specific DApp contract), and expiration time.
3. DApp Transfer Request Using Signature: When a DApp receives the user’s signature and needs to use tokens, instead of calling the token contract directly, it calls Permit2’s functions (like permitTransferFrom). This function verifies the user’s signature data and confirms the operation is within granted permissions (token, amount, deadline). After verification, Permit2 uses its master approval to call transferFrom, moving tokens from the user to the specified recipient. Key point: Permit2 contract itself acts as the spender, using its own authority to transfer tokens, with an additional signature verification step.
4. Operation Completion: Once Permit2 successfully executes transferFrom, funds move smoothly from the user to the DApp or specified address. From the user’s perspective, they only provide a signature in the transaction, while the contract handles all subsequent actions.

The Permit2 authorization flow is straightforward: users only need to grant maximum approval to Permit2 once per token. Afterward, when interacting with applications (like Uniswap Universal Router or other protocols), they simply include a Permit2 signature in their transaction to complete authorization and transfer, without additional on-chain approvals. The Permit2 contract verifies the signature and executes the transfer using its master approval. (Source: Introducing Permit2 & Universal Router)

Through this model, Permit2 extends EIP-2612’s signature-based authorization concept to all ERC-20 tokens, regardless of whether they implement the permit() method themselves. As long as users initially authorize the Permit2 contract, they can use signatures for subsequent operations. Notably, Uniswap designed Permit2 as an ownerless, non-upgradeable contract deployed with the same address across Ethereum mainnet and multiple Layer 2 networks. This means all applications actually use the same Permit2 instance, achieving true “approve once, use everywhere” functionality.

Key Features of Permit2

As a next-generation authorization system, Permit2 not only enables signature-based approvals for all tokens but also offers additional features to enhance security and usability. Here are its main features:

Automatic Expiration
All Permit2 authorizations can include a timestamp for expiration. Users can specify when their sub-authorization should expire when signing. Once the deadline passes, Permit2 will reject the signature, even if the master approval is still active. This effectively addresses the risk of indefinite approvals lingering unused.

Single-Use Signature Transfers
Permit2 offers a direct signature transfer mode where users can authorize a specific token transfer to a recipient using just a signature, without needing to set an allowance first. This is perfect for one-time payment scenarios: users can sign a message authorizing the transfer of 100 tokens to a friend’s address, and the friend or intermediary can execute the transfer using this signature. Once used, the signature becomes invalid, leaving no lingering permissions.

Batch Approvals and Transfers
Permit2 prioritizes efficiency by allowing batch processing of multiple approvals or transfers. Users can authorize different amounts of multiple tokens to a single protocol with one signature, or execute transfers of multiple tokens in a single transaction. This saves Gas and reduces steps for advanced users.

Batch Revocation
Beyond batch approvals, users can revoke permissions for multiple tokens/applications in a single transaction. This makes cleaning up historical approvals much more convenient.

Additional Data Witnessing
Permit2 includes interfaces like permitWitnessTransferFrom that allow additional verification data to be included in signatures. This supports more complex scenarios, such as including specific transaction details in order signatures to prevent signature reuse in different contexts.

Through these features, Permit2 not only replicates all the benefits of Permit but also enhances flexibility and security controls. The automatic expiration and single-use signature transfers, in particular, make minimal necessary authorization the norm, reducing long-term risks.

To summarize, Permit2 functions as both an extension and an enhancement of the traditional Permit mechanism. Let’s examine the key differences between these two approaches:

Permit2 Ecosystem Adoption and Implementation

Since Uniswap introduced Permit2, numerous projects have integrated this mechanism, accelerating industry standardization. According to the latest data from Dune Analytics, as of April 2025, over 3.1 million Ethereum mainnet addresses have granted authorization to the Permit2 contract, demonstrating its widespread adoption.

Permit2 Ecosystem and Implementation Status. Source: Dune Analytics

For instance, Uniswap has integrated Permit2 into its Universal Router, enabling multi-token and NFT exchanges in a single transaction. Through Universal Router, users can chain multiple operations in one transaction, such as exchanging three tokens for two target tokens and purchasing NFTs, with all authorization requirements handled by Permit2 signatures. This significantly streamlines the process and reduces total Gas costs, showcasing Permit2’s direct impact on improving user experience.

Furthermore, with Permit2’s open-source deployment across various chains, an increasing number of wallets and DApp tools have begun supporting it. Security tools like Revoke.cash have updated their services to allow users to view and revoke Permit2 authorization records. Matcha has also implemented Permit2’s SignatureTransfer module, enabling a “one-time authorization” mechanism.

Despite this progress, Permit2’s widespread adoption faces challenges. On one hand, developers need additional time for integration: compared to using ERC-20’s approve directly, implementing Permit2 requires handling signature logic, increasing development overhead. This might deter smaller teams. On the other hand, user education is crucial: many DApps using Permit2 need to teach users about the significance of signatures. Currently, Permit2’s unified advantages appear to outweigh these friction points, but full market penetration will still take time.

Comparing Permit2 with New Solutions: Session Keys and ERC-4337

Over the past 8 years, ERC-20 authorization mechanisms have evolved from multiple transactions to gasless signatures and now to smart accounts. Each advancement has sought to optimize the balance between user experience (reducing transaction and signature requirements) and gas costs. Here’s a comparison of these technologies:

Besides Permit2, two emerging authorization solutions worth noting are Session Keys and ERC-4337 Account Abstraction, each offering distinct approaches to the problem.

Session Keys are particularly unique, as they’re not a strict authorization model but rather a temporary key mechanism at the wallet or account level. Instead of modifying token contracts, they allow wallets to generate time-limited, amount-restricted temporary private keys for specific operations. This makes them ideal for gaming item purchases and one-time micropayments. Their focus is on reducing single-authorization risks, designed specifically for temporary user interactions, unlike the contract-modification approach of Permit/Permit2.

ERC-4337 takes a different approach by embedding authorization logic directly into smart accounts, allowing users to customize authorization conditions and potentially skip traditional approval steps. Through flexible UserOperation and Paymaster mechanisms, it achieves enhanced security and user experience.

Looking at future trends, these different solutions are likely to coexist. In the short term, Permit2 will continue to be the standard for emerging DApps, improving user experience through one-time authorizations while promoting security education and tool support to reduce phishing risks. In the medium term, as ERC-4337 and account abstraction become more widespread across Layer 2s and mainnets, users will be able to break free from traditional ERC-20 approve limitations, managing authorizations more precisely and intelligently, potentially reducing the need for Permit2.

The long-term vision is to create an authorization experience as seamless and intuitive as Web2, where users can simply click a button and all necessary approvals happen automatically in the background, with clear prompts appearing only in high-risk situations. Achieving this vision will require continuous collaboration and innovation across underlying protocols, wallets, and dApps. Permit2 represents an important step in this transitional journey, but there is still a long way to go before reaching the ideal state. Along the way, both the community and developers should maintain a pragmatic approach, fully understanding the strengths and limitations of each solution and working together to build a safer and more user-friendly authorization environment.

Overall, Permit2 offers a practical solution that can be implemented immediately, while technologies like Session Keys and ERC-4337 point toward more fundamental and long-term improvements in how authorization is handled.

Security Risks of Signature-Based Authorization

As with any new technology, Permit and Permit2 introduce not only new efficiencies but also new risks, particularly around signature-based authorization attacks.

In signature-based schemes like Permit2 and EIP-2612 Permit, core contract designs include multiple layers of protection to guard against misuse and replay attacks:

1. Nonce-Based Replay Protection

Permit2 maintains a separate nonce counter for each (owner, token, spender) tuple. Every time a user signs a new authorization, the corresponding nonce is incremented. If an attacker tries to reuse an old signature, it will fail because the contract checks whether the nonce has already been used.

2. Deadline Enforcement

Each signature must include a deadline field. When the contract verifies the signature, it ensures the current block time is less than or equal to the deadline. If the signature has expired—even if it’s otherwise valid—it will be rejected. This prevents long-lived authorizations from being exploited later.

3. Fine-Grained Allowance Control

Permit2 signatures can specify a maximum allowance. Before any token transfer occurs, the contract checks that the requested amount is within this limit. The contract does not automatically spend the full approved amount, allowing users to use their allowance in parts and reducing the risk of a full-drain exploit.

4. Single-Use and Batch Modes

In addition to ongoing allowance-based approvals, Permit2 also supports single-use signatures via SignatureTransfer. These signatures are valid for one transaction only and become invalid immediately after execution. This is ideal for one-time payments and prevents the signature from being reused or exploited later.

These layered protections help Permit-style authorization schemes improve user experience and save gas while also minimizing classic risks like “replay attacks”, “over-authorization”, and “indefinite signature validity”.

However, even with secure contract-level protections, social engineering (especially phishing) remains the most difficult threat to defend against. In the next section, we’ll look at common phishing tactics and how attackers trick users into unknowingly signing malicious approvals that abuse Permit2. We’ll also offer tips on how to stay safe.

How Do Signature Phishing Attacks Happen?

Signature phishing occurs when attackers trick victims into signing specific messages to gain control of their assets. While traditional attacks might involve executing malicious contracts or transactions, in the Permit era, a single malicious signature authorization is enough to drain funds. Here’s how these attacks typically unfold:

1. The victim clicks on a fake version of a well-known DEX website (phishing site). When the user tries to interact, the site prompts a wallet signature request, claiming it’s for “login confirmation” or other seemingly legitimate purposes. However, this request is actually a Permit2 authorization signature, granting the attacker’s contract unlimited permission to withdraw the victim’s USDC with an extended validity period.
2. The victim, lacking vigilance, signs the request directly. At this point, no gas is spent and no on-chain activity occurs, leaving no suspicious traces.
3. Once the attacker obtains the signature, they immediately call the Permit2 contract’s permit() function to submit it. After the Permit2 contract validates the signature, it records the authorization for the attacker’s contract under the victim’s address (equivalent to the victim executing an approve, but completed by the attacker). This operation might still go unnoticed by the victim since their wallet shows no expenditure - only their token allowance mapping is updated on the blockchain.
4. Subsequently, the attacker immediately initiates a transferFrom(victim, attacker_address, amount) transaction from their address, successfully transferring the victim’s USDC using the recent Permit2 authorization. The victim only realizes the theft when it’s too late.

In these attacks, users never execute any obvious “transfer” or “authorization” transactions, yet their assets mysteriously disappear. The key lies in the signature itself becoming the authorization. Attackers carefully disguise signature requests to appear as normal operations, lowering users’ guard. However, once signed, it’s like handing over the keys to your assets.

Even worse, some attackers employ technical methods to increase stealth. For instance, they use Ethereum’s CREATE2 mechanism to generate unique malicious contract addresses for each victim. This makes traditional blacklists ineffective since each attack uses a different address.

Most recent crypto phishing incidents involve signature authorization. For example, Scam Sniffer’s statistics from early 2024 show over $55 million in assets stolen through signature phishing in just one month. Since Permit2’s activation, attackers have become more aggressive in inducing users to sign Permit/Permit2 authorizations, leading to numerous victims in a short period. Clearly, when signature authorization is abused, it can be devastating and hard to detect.

Why are Signature-Based Phishing Risks Higher than Traditional Methods?

Traditional malicious authorizations require users to execute an on-chain transaction, where wallets typically display clear warnings like “You are authorizing XXX to use your tokens” and require gas fees. Experienced users tend to be more cautious about these. However, signature requests in wallet interfaces are often described merely as “data signature requests” rather than financial actions, causing users to lower their guard. Moreover, since signatures don’t cost gas, attackers can launch large-scale phishing attempts without worrying about expenses - they profit even with just a few successful attempts.

Additionally, different wallets display EIP-712 messages in various ways. Some modern wallets (like the latest MetaMask ) parse and display fields clearly, showing messages like “authorize contract to spend X amount of your tokens.” However, many wallets only show hexadecimal data or simple descriptions, making it difficult for average users to verify authenticity. Attackers exploit this by embedding deceptive descriptions in messages (like pretending to be NFT mint signatures) to trick users into signing.

Because signature authorizations don’t immediately impact assets, victims may not detect the threat immediately. Attackers can strategically time their strikes. Rather than executing right away, they might wait until the victim’s wallet contains more assets or until a specific moment, which complicates tracking efforts. With signatures that have extended validity periods, attackers can also exploit price movements to maximize their gains, effectively giving them a free trading option. This risk explains why Permit signatures typically enforce short deadlines.

Permit2’s ability to authorize multiple tokens with a single signature makes it particularly challenging for users to understand the implications fully. For example, a phishing website might request a Permit2 signature while highlighting permissions for only one or two tokens, yet secretly embed extensive authorizations for additional tokens within the same signature. Users can easily overlook these hidden permissions if their wallets don’t display all details clearly. Furthermore, attackers often use deceptive contract names like “WalletGuard” in their signatures, masking malicious contracts designed to steal token permissions.

How Can Users Protect Themselves from Signature Attacks?

Remember that signing is equivalent to giving consent—never let the absence of gas fees make you careless. When your wallet requests a signature, read the message details thoroughly. Ensure the website or DApp requesting the signature is legitimate and that the message content aligns with your intended actions. For instance, if you’re simply logging into a website, the signature should contain readable login text (as most DApps use), not a string of token addresses and numbers.

Make sure your wallet software supports EIP-712 data display. Major wallets like MetaMask, TrustWallet, and Ledger Live are improving their signature content display experience. For instance, MetaMask can now parse common permission messages into plain language. If your wallet only shows long hexadecimal data when signing, consider switching or updating. Hardware wallet users should also keep their firmware updated to support new formats, or they might not see information correctly on screen.

Whether using Permit signatures or Permit2, you can usually adjust authorization parameters. Don’t sign unlimited amounts (value = 2^256-1) unless absolutely necessary - instead, only authorize the amount you need plus a small buffer. Also, don’t set deadlines too far in the future. This way, even if your signature falls into the wrong hands, potential losses are limited, and the signature will eventually expire.

Develop a habit of regularly checking your address’s authorization status using tools like Revoke.cash, Etherscan Token Approval, or your wallet’s built-in features. This includes both traditional approvals and Permit2 allowances. If you spot any suspicious or unnecessary authorizations, revoke them immediately. For Permit2, be aware of two levels of revocation: first, the master authorization (your approve to the Permit2 contract itself, which you might want to set to 0 when not in use); second, sub-authorizations (Permit2’s allowances to various DApps, which usually auto-expire but can be terminated early if they have long validity periods). If you suspect you’ve signed a suspicious Permit, the safest action is to immediately adjust the nonce: sign a new permit to the same spender (even with 0 allowance) to invalidate the old signature in the attacker’s possession.

Always be cautious when visiting unfamiliar websites or downloading applications. Don’t click on unknown links, especially “promotional offers” or “mint events” shared through social media ads or private messages. Many phishing attempts occur through fake official accounts that post fraudulent activity links, leading to signature requests. Make it a habit to directly type in official DApp URLs or use bookmarks to avoid falling for fake websites.

In conclusion, striking a balance between convenience and security is crucial. While Permit technologies are convenient, users must remain vigilant about risk prevention. As the ecosystem matures, wallet products and browser plugins are developing protection against signature phishing, such as warnings for signatures involving large amounts. We aim to mitigate such attacks through both technical and educational enhancements in the future.

Conclusion

From the limitations of traditional ERC-20 authorization models to the birth of Permit, and then to Uniswap’s innovative Permit2, we have witnessed the Ethereum ecosystem’s efforts to improve user experience and security. Permit2 significantly simplifies the token authorization process through off-chain signatures, reducing the risks of repeated approvals and unlimited permissions, while introducing useful features like expiration mechanisms and batch operations. However, these new mechanisms come with new responsibilities—users need to enhance their security awareness, while wallets and DApps must work together to protect users from signature attacks. Looking ahead, with further technological developments, such as account abstraction, token authorization management is expected to become more seamless and secure.