permit2-patterns
Skill36 starsChanged 5 months agoMITView on GitHub
Detect Permit2 / EIP-2612 lifecycle bugs — signature lifecycle, allowance transfer vs signature transfer confusion, nonce reuse, deadline manipulation, witness-data misuse. Activate on `permit`, `permitTransferFrom`, `IPermit2`, `SignatureTransfer`, `AllowanceTransfer`, `PermitWitnessTransferFrom`, `PermitBatchTransferFrom`.
In this repository44 other files it gives its agents.
- access-controlSkill
- approval-issuesSkill
- caching-and-incrementalSkill
- centralization-riskSkill
- confidence-scoringSkill
- cosmwasmSkill
- cross-chain-messagingSkill
- cross-contract-stateSkill
- delegatecall-risksSkill
- diamond-eip2535Skill
- dos-vectorsSkill
- erc1271-contract-signaturesSkill
- erc4337-account-abstractionSkill
- erc4626-inflationSkill
- false-positive-feedback-loopSkill
- fee-on-transferSkill
- flash-loan-attacksSkill
- initializationSkill
- inline-assemblySkill
- integer-issuesSkill
- intents-erc7683Skill
- known-good-comparisonSkill
- liquidation-cascadeSkill
- mev-frontrunningSkill
- mev-pbsSkill
- multi-pass-self-critiqueSkill
- oracle-manipulationSkill
- oracle-redundancySkill
- pragma-and-addressesSkill
- progress-and-streamingSkill
- reentrancySkill
- restaking-eigenlayerSkill
- selfdestruct-eip6780Skill
- signature-malleabilitySkill
- signature-replaySkill
- solana-anchorSkill
- storage-layoutSkill
- stylus-rustSkill
- token-compatibilitySkill
- tx-context-misuseSkill
- unchecked-callsSkill
- ve-lock-governanceSkill
- vyper-specificSkill
- zk-verifier-bugsSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 85
Use Permit2's canonical contracts via OZ / Uniswap reference impls.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Permit2 / EIP-2612 detection
Background
EIP-2612 (permit) — token-native gasless approval, per-token nonce.
Permit2 (Uniswap) — canonical contract bridging legacy ERC20s into the permit world; two APIs:
- SignatureTransfer — one-shot, sig consumed atomically.
- AllowanceTransfer — persistent allowance with nonce + expiration.
When this applies
- Routers, swap aggregators, vaults using Permit2 / EIP-2612 for gasless approve flows
- Custom permit implementations
- Apps calling
IPermit2.permitTransferFrom,permitWitnessTransferFrom,permit
Detection patterns
Permit2 permitTransferFrom without amount check (CRITICAL)
permit2.permitTransferFrom(permit, transferDetails, owner, signature);
// uses `transferDetails.requestedAmount` — caller-controlledCaller can request permit.permitted.amount (the max), regardless of intent. App must enforce the actual transfer amount.
Witness data ignored (HIGH)
permitWitnessTransferFrom includes a user-signed witness blob. App must validate it matches the intended action; otherwise sig can be reused with different context.
SignatureTransfer vs AllowanceTransfer confusion (HIGH)
SignatureTransfer is one-shot. AllowanceTransfer is persistent with nonce + expiration. Mixing → over-approval or replay.
Allowance not invalidated after one-shot use (HIGH)
Some implementations using AllowanceTransfer don't increment nonce after consumption.
Missing deadline (HIGH)
Permit sigs without deadline are bearer instruments forever.
EIP-2612 permit failure swallowed (MEDIUM)
try IERC20Permit(token).permit(...) {} catch {}
token.transferFrom(...); // ← if permit fails, falls back to stale allowanceAcceptable IFF the app then validates allowance is sufficient.
Permit + transferFrom unbundled (MEDIUM — MEV)
Submitting permit in one tx then transferFrom in another lets a searcher front-run the permit and grief.
Hardcoded chainId / DOMAIN_SEPARATOR cached (HIGH)
Some EIP-2612 impls cache DOMAIN_SEPARATOR in constructor. Post-chain-fork, this is wrong. Re-derive based on block.chainid. See [[signature-replay]].
DAI-style permit (HIGH)
DAI uses a non-standard permit signature (allowed-bool, no amount). Apps that hit DAI with standard EIP-2612 ABI will revert.
USDC EIP-3009 (different from EIP-2612) (MEDIUM)
USDC uses transferWithAuthorization / receiveWithAuthorization instead of permit on most chains. Apps assuming permit-on-USDC break.
Nonce reuse across signers (HIGH)
Custom permit impls that use a global nonce instead of per-signer nonce → cross-signer collision.
Bitmap nonce model assumed but not used (HIGH)
Permit2 uses a bitmap for nonces (word index + bit). Custom forks sometimes simplify this and break.
Severity rubric
| Pattern | Severity |
permitTransferFrom with caller-controlled requestedAmount | Critical |
| AllowanceTransfer not invalidating nonce on one-shot use | High |
| Sig without deadline | High |
| Cached DOMAIN_SEPARATOR not fork-aware | High |
| Witness ignored in permitWitnessTransferFrom | High |
| Failed permit swallowed, allowance not re-checked | Medium |
| Permit + tx unbundled (MEV grief) | Medium |
| DAI/USDC-specific sig variant mishandled | High |
| Global nonce instead of per-signer | High |
Remediation patterns
- App-side: validate
transferDetails.requestedAmount <= permit.permitted.amountAND matches intent. - Bundle
permit+ consuming op in one tx. - Use Permit2's canonical contracts via OZ / Uniswap reference impls.
- For DAI / USDC: dispatch on token type, use appropriate sig variant.
- For chain forks: re-derive
DOMAIN_SEPARATORwhen chainId changes.
False-positive notes
- Apps that just call
IERC20Permit.permit(...)directly and don't trust the result are typically fine. - Uniswap V4 / Universal Router use Permit2 canonically — audit how they pass requestedAmount.
Related
- [[signature-replay]]
- [[approval-issues]]
- [[mev-frontrunning]]
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

