> For the complete documentation index, see [llms.txt](https://help.tokenpocket.pro/en/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.tokenpocket.pro/en/wallet-faq-en/eth-wallet/permit2-token-authorization.md).

# About Permit2 Authorization for Contracts to Use Tokens

Understand how Permit2 authorization works and identify asset risks associated with authorized addresses or contracts.

## What Is Permit2 Authorization

Permit2 is a universal token approval contract mechanism introduced by Uniswap. It is designed to help users manage token approvals more flexibly when performing Swap, DeFi, aggregator trading, and other on-chain operations.

In practice, users may encounter operations such as “authorizing a contract to use USDT via Permit2.” This process is often mistaken for a standard token approval, but it usually involves two layers of permissions:

1. The user approves USDT to the Permit2 contract;
2. The user then authorizes a specific trading contract, DApp, or Spender to use USDT through Permit2.

Understanding the difference between these two layers of authorization is important for identifying authorization risks, investigating abnormal asset transfers, and revoking suspicious approvals.

### 1. What Does It Mean to Approve USDT to Permit2

“Approving USDT to Permit2” is a standard ERC-20 approval operation that takes place at the USDT token contract level.

When a user executes the `approve` operation on the USDT contract and sets the approved spender as the Permit2 contract address, it means the user allows the Permit2 contract to call the `transferFrom` function of the USDT contract within the approved allowance.

Simply put, this step means:

> The user allows the Permit2 contract to manage or transfer their USDT within the approved allowance.

It is important to note that approving USDT to Permit2 does not mean that any DApp can directly transfer the user’s USDT.

At this stage, the USDT contract only recognizes that:

> The Permit2 contract is allowed to use the user’s USDT.

However, which specific DApp, trading contract, or Spender can use these USDT through Permit2 still requires further authorization inside the Permit2 contract.

### 2. What Does It Mean to Authorize a Trading Contract to Use USDT via Permit2

“Authorizing a trading contract to use USDT via Permit2” usually refers to an internal authorization or signature-based authorization within Permit2.

When a user signs a message on a DApp page, they may authorize a specific `spender` to use their USDT. This `spender` may be:

* A Swap Router;
* A trading contract;
* An aggregator contract;
* A third-party DApp contract;
* Another address that can call Permit2.

This step means:

> Permit2 already has permission to call the USDT contract, and the user further allows a specific contract or address to use their USDT through Permit2.

It can be understood as follows:

1. The user first tells the USDT contract: “I allow Permit2 to use my USDT.”
2. The user then tells Permit2: “I allow this specific trading contract to use my USDT through Permit2 within a certain amount and validity period.”

Therefore, the conditions that can actually trigger an asset transfer are usually:

```
USDT contract approval to Permit2
+
Permit2 internal authorization to a specific Spender
```

Only when both layers of authorization are in place can the trading contract transfer USDT from the user’s address through Permit2.

### 3. Key Differences Between the Two Types of Authorization

The following table shows the key differences between “approving USDT to Permit2” and “authorizing a trading contract to use USDT via Permit2”:

| Item                                 | Approving USDT to Permit2                                            | Authorizing a Trading Contract to Use USDT via Permit2            |
| ------------------------------------ | -------------------------------------------------------------------- | ----------------------------------------------------------------- |
| Where the authorization takes place  | USDT token contract                                                  | Inside the Permit2 contract                                       |
| Authorized party                     | Permit2 contract                                                     | A specific DApp, trading contract, or Spender                     |
| Purpose                              | Allows Permit2 to manage or transfer USDT                            | Allows a specific contract to use USDT through Permit2            |
| Whether a DApp is directly specified | No                                                                   | Yes                                                               |
| Main risk                            | Permit2 becomes a unified authorization entry point                  | A malicious Spender may transfer assets through Permit2           |
| How to revoke                        | Revoke the approval granted to Permit2 in the USDT approval settings | Revoke the corresponding Spender authorization in Permit2 records |

From a risk perspective, users should not only check whether USDT has been approved to Permit2. They also need to further check whether there are any suspicious Spender authorizations inside Permit2.

### 4. Risks of Permit2 Authorization

Permit2 itself is a common authorization mechanism and is not equivalent to a malicious contract. Its purpose is to improve approval efficiency and reduce repeated approval operations.

However, the risks include:

* Users may not be able to clearly understand the signing content;
* Malicious DApps may disguise themselves as legitimate trading pages;
* Users may authorize unknown Spenders;
* The approved allowance may be unlimited;
* The authorization validity period may be very long;
* Users may ignore risk warnings shown by their wallet.

Once a user grants Permit2 authorization to a malicious Spender, and USDT has already been approved to Permit2, the malicious contract may transfer the user’s assets through Permit2.

Therefore, before signing or authorizing on any website, users should confirm:

* Whether the website they are visiting is trustworthy;
* Whether the token being authorized is correct;
* Whether the authorization amount is reasonable;
* Whether the authorized party is trustworthy;
* Whether there is any unlimited or long-term authorization;
* Whether the wallet has displayed any risk warning.

### 5. Security Recommendations

To reduce risks related to Permit2 authorization, users are advised to follow these security principles:

* Only grant authorizations or sign messages on trusted DApps;
* Do not randomly click unknown links to access DApps;
* Do not trust third-party groups, private messages, airdrops, mining offers, staking rebates, or other misleading promotions;
* Carefully review wallet pop-up risk warnings before authorizing;
* Avoid unlimited approvals whenever possible;
* Regularly check and remove unused authorizations;
* Stay cautious of unknown Spenders;
* Do not sign any Permit or Permit2 messages on unknown websites;
* Revoke abnormal authorizations as soon as they are found;
* If abnormal asset transfers are detected, stop using the wallet to receive assets.

### 6. Summary

Permit2 authorization can usually be divided into two layers:

```
Layer 1: USDT is approved to Permit2
Layer 2: Permit2 authorizes a specific Spender to use USDT
```

“Approving USDT to Permit2” only makes Permit2 the token authorization entry point. “Authorizing a trading contract to use USDT via Permit2” means allowing a specific contract or address to use the user’s USDT through Permit2.

Therefore, when checking authorization risks, users should not only check whether the token has been approved to Permit2. They also need to check which specific Spenders have been authorized inside Permit2.

If a user mistakenly signs a malicious DApp’s Permit2 authorization, and USDT has already been approved to Permit2, the malicious Spender may transfer the user’s assets within the authorized allowance and validity period.

Carefully reviewing risk warnings, verifying the authorized party, and avoiding unlimited approvals are important steps for protecting asset security.

Spender is not the project itself. It refers to the specific address or contract that can use a user’s tokens after being authorized. It can be understood as “the party authorized to use the assets.”