You notice the Permit2 authorization page clearly says "valid for 30 days," but after it expires, the DApp interface still shows "Available." This isn't a system bug, and your authorization hasn't failed to expire. The root cause is the DApp frontend displays the historical state of "you authorized this contract before," while the Permit2 contract checks the current state of "whether the signature is still within its validity period." These two things use different standards, so the display logic differs.
Step 1: Understand Permit2's Two-Layer Authorization Structure
Permit2 isn't a simple single-layer authorization. It manages your permissions on two levels:
First layer (on-chain authorization): You grant the Permit2 contract itself an on-chain
approve, typically for an unlimited amount (type(uint256).max). This layer has no expiration date. Once authorized, it stays valid until you actively revoke it.Second layer (off-chain signature authorization): Every time you interact through a DApp, you sign a
PermitSinglestructure that includesexpiration(authorization validity) andsigDeadline(signature validity) timestamps. This layer's default validity is 30 days.
When a DApp frontend displays "Available," it usually refers to the first layer (on-chain) authorization still existing. As long as the Permit2 contract can still call transferFrom, the interface shows "Authorized." It won't automatically switch status just because the second-layer signature expired, because the webpage can't see whether your most recent signature is still valid.
Step 2: Confirm Which Layer Has Expired
What to do: Distinguish whether you're seeing "signature expired" or "authorization revoked."
How to do it:
Recall your action: The last time you used this DApp, did you re-sign a Permit2 signature, or did you just click "Swap" and the process completed?
Check Permit2 allowance: Connect your wallet to Revoke.cash and view the Permit2 contract's allowance for that token. If the allowance is still
type(uint256).max, it means the first-layer authorization was never revoked—only the second-layer signature's 30-day window has ended.Inspect Permit2 contract state: On a block explorer, call
Permit2.allowance(userAddress, tokenAddress, spenderAddress)and check the returnedexpirationfield. If thisexpirationis far greater than the current block timestamp, the second-layer signature is still valid. Ifexpirationis already less than the current time, the second-layer signature has expired, but the first layer remains.
Completion standard: You now know exactly where you're stuck: whether you never actively revoked the authorization and only the signature expired, or whether you already clicked "Revoke" on Revoke.cash and set the allowance to zero.
Common pitfall: Many people think clicking "Revoke" on Revoke.cash only targets traditional approvals, but Revoke.cash also supports revoking Permit2 contract authorizations. If you did revoke, the allowance goes to zero, and the DApp should no longer display "Available." If it still shows "Available," it might be a frontend cache issue—refresh the page or clear your cache.
Step 3: Determine What DApp's 'Available' Actually Means
What to do: Confirm whether the DApp's "Available" means "you can still initiate a signature" or "no new authorization is needed."
How to do it:
Case A: The DApp says "Available," but asks you to sign again when you start a transaction. This is normal. The second-layer signature expired, but the first-layer authorization is still there, so you only need to spend gas to sign a new Permit2 signature—no on-chain
approvetransaction required. This is exactly where Permit2 saves gas compared to traditional approvals.Case B: The DApp says "Available," and skips the signature step entirely when you start a transaction. This means your second-layer signature hasn't expired yet. The system is reusing the signature you signed earlier. Uniswap's default signature validity is 30 days, so within those 30 days, you don't need to sign again.
High-risk scenario: If you revoke the Permit2 contract authorization after the first layer (allowance goes to zero), but the DApp frontend still shows "Available," this may be caused by frontend cache or RPC node synchronization delay. If you initiate a transaction in this state, it will revert on-chain due to insufficient allowance, and you'll waste gas. How to handle: refresh the DApp page or switch to a different RPC node before trying again.
How to verify: After going through the above logic, initiate a small test transaction (e.g., 1 USDT). If the transaction succeeds, your judgment is correct. If it fails with ERC20: insufficient allowance, the first-layer authorization was indeed revoked, and you need to go through the on-chain approve process again.
