Permit No-Op / Non-Standard Permit
⚡ MEDIUM severityWETH's permit function is a no-op — it does not revert but does nothing. Attackers can exploit this to create phantom approvals, bypassing permit-based authorization flows. This caused the $130M+ Multichain incident.
Related: Unchecked Return Values
Do not rely on permit() for WETH. Instead use traditional approve+transferFrom flow, or explicitly check allowance after permit calls.
| Chain | Address |
|---|---|
| Ethereum | 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 |
| Polygon | 0x7ceb23fd6bc0add59e62ac25578270cff1b9f619 |
| Arbitrum | 0x82af49447d8a07e3bd95bd0d56f35241523fbab1 |
| Base | 0x4200000000000000000000000000000000000006 |
Audit any contract that interacts with WETH: SmartContract.us automatically detects WETH integration risks →
Read live from Ethereum on 2026-10-14. This is a different question from the integration risk above: not how to call the token safely, but what the holders of its keys are able to do to the people holding it.
| Question | Answer |
|---|---|
| Can new tokens be created? | No |
| Can transfers be blocked? | No |
| Is there a trading tax? | No |
| Can the logic be replaced? | No |
| Can liquidity be withdrawn? | Yes |
No privileged address could be identified. This is not the same as there being none — see the limitation below.